development process

[Peter]

Hi
In cmomerical software house, i haven't seem several programmers
edit the same source file, right? Actually bussiness company want to
prevent multi-programmers edit the same source file, but CVS doesn't
provide this function, it focus on "multiple edit", so that why
bussiness company don't use CVS.
the development method of CVS is "copy-modify-merge", VSS is
"lock-modify-commit". CVS guy say "lock-modify-commit" is a desuete
method, but they forget this is what business company do.
thanks
from Peter ([email protected])

 

[Oscar kind]

In cmomerical software house, i haven't seem several programmers
edit the same source file, right? Actually bussiness company want to
prevent multi-programmers edit the same source file, but CVS doesn't
provide this function, it focus on "multiple edit", so that why
bussiness company don't use CVS.

Not nescessarily: my company uses CVS, as it is a de facto standard (one
of two: the other being Visual Source Safe for Microsoft shops).

But even then it's better not to work with several people on the same
file, as you get merge conflicts and the possibility of bugs because new
code depends on other code that just changed.

the development method of CVS is "copy-modify-merge", VSS is
"lock-modify-commit". CVS guy say "lock-modify-commit" is a desuete
method, but they forget this is what business company do.

If companies don't, they at least use divide-modify-commit (the divide
part being the division of the files to work on among the developers).
IMHO it's still good to have a versioning tool that allows multiple
developers to work on one file though, so one person can, for example,
make minor page modifications across all files.

 

[Karel Suikers]

Oscar kind schreef:

Not nescessarily: my company uses CVS, as it is a de facto standard (one
of two: the other being Visual Source Safe for Microsoft shops).

Or PVCS (serena.com), the one my company uses. If I was the financial
guy, I would prefer CVS.

 

[Grant Edwards]

In cmomerical software house, i haven't seem several programmers
edit the same source file, right? Actually bussiness company want to
prevent multi-programmers edit the same source file, but CVS doesn't
provide this function, it focus on "multiple edit", so that why
bussiness company don't use CVS.

Some do.

the development method of CVS is "copy-modify-merge", VSS is
"lock-modify-commit". CVS guy say "lock-modify-commit" is a desuete
method, but they forget this is what business company do.

So? That's whey there are different version control systems
around: different people/organizations prefer different models.

thanks

You're welcome.

 

[Antti S. Brax]

Please set Followup-To header when crossposting.

In cmomerical software house, i haven't seem several programmers
edit the same source file, right? Actually bussiness company want to
prevent multi-programmers edit the same source file, but CVS doesn't
provide this function, it focus on "multiple edit", so that why
bussiness company don't use CVS.

If you have problems with concurrent editing then you have a
communication problem. Solve it by improving communication, not
by imposing technical restrictions on people.

 

[Darryl Pierce]

In cmomerical software house, i haven't seem several programmers
edit the same source file, right? Actually bussiness company want to
prevent multi-programmers edit the same source file, but CVS doesn't
provide this function, it focus on "multiple edit", so that why
bussiness company don't use CVS.

CVS allows for people to edit the same version of a file and then check
in those changes at different points. It's called *merging* and CVS
handles it fine, provide two people don't modify the *same* lines in the
original version.

the development method of CVS is "copy-modify-merge", VSS is
"lock-modify-commit". CVS guy say "lock-modify-commit" is a desuete
method, but they forget this is what business company do.

What does this have to do with *Java*?

 

[Darryl Pierce]

Or PVCS (serena.com), the one my company uses. If I was the financial
guy, I would prefer CVS.

I've been playing with Subversion for the past few months and find it to
be much more attractive than CVS.

 

[NoDot]

What does this have to do with *Java*?

I know. You'd think there'd be some comp.design.methology group he could
post to. (I'm receiving this in alt.lang.asm here, and it'd be best if
the thread was backed out of here before Betov comes in...)

 

[Percival]

What does this have to do with *Java*?

A bigger question, what does this have to do with *Assembly* ??

Percival

 

[Dotty]

Hi
In cmomerical software house, i haven't seem several programmers
edit the same source file, right? Actually bussiness company want to
prevent multi-programmers edit the same source file, but CVS doesn't
provide this function, it focus on "multiple edit", so that why
bussiness company don't use CVS.
the development method of CVS is "copy-modify-merge", VSS is
"lock-modify-commit". CVS guy say "lock-modify-commit" is a desuete
method, but they forget this is what business company do.
thanks
from Peter ([email protected])

Lock is better.
Last big company I worked at used lock. Then first one to lock the file
knows that when they commit that there will be no problem. Second one
can still get a copy of the file to edit simultaneously, but then they
know for sure that someone else is changing the file too. Lock is also
a mechanism to guarantee that no changes are made, for example, during
the month prior to ship. The 'owner' of the file locks it. With CVS it
can change 5 seconds prior to final build for ship.

 

[Antti S. Brax]

Set the Follow-Up header when crossposting.

Lock is also a mechanism to guarantee that no changes are made, for
example, during the month prior to ship. The 'owner' of the file
locks it.

Is all development on the project freezed during this month?

With CVS it can change 5 seconds prior to final build for ship.

Please learn to use the tools before you start bashing them.

There is this concept that CVS people call "tags". When you
check out code and start testing it you tag it as a release
candidate. If that checked out code works well enough you tag
it as the final release. If someone makes reckless changes to
the file when s/he should not, you can roll back to the working
version and give the boot to the bastard. And then there are
"branches" too.

And again the problem that you describe is in communication.
The lack of locks in a VCS is only a problem if you can not
communicate with your programmers or if your programmers do
not follow rules. The former problem can easily be fixed by
improving communication and the latter by educating or firing
people.

IMHO introducing locks will only make life difficult to those
who know what they are doing and follow the rules. Those people
usually are the ones that you absolutely do not want to piss
off (ie. the good employees).

 

[Dotty]

Set the Follow-Up header when crossposting.



Is all development on the project freezed during this month?

Of course. This is the testing interval.

Please learn to use the tools before you start bashing them.

From what you describe below, it can be changed whenever anyone
wants to do it.

There is this concept that CVS people call "tags". When you
check out code and start testing it you tag it as a release
candidate. If that checked out code works well enough you tag
it as the final release. If someone makes reckless changes to
the file when s/he should not, you can roll back to the working
version and give the boot to the bastard. And then there are
"branches" too.

The reason for the freeze is to allow time for final test. If you
allow changes, the testing has to be done over.

And again the problem that you describe is in communication.

Yes, but if the official 'company' position is 'xyz' it is necessary
to be able to tell customers that the company position has been
maintained independent of any last minute 'mistakes'. Did you ever
check in a file that had a bug in it?

If you read the book about the development of WIN NT you will see
that MS did not allow changes during the final test interval.

The lack of locks in a VCS is only a problem if you can not
communicate with your programmers or if your programmers do
not follow rules. The former problem can easily be fixed by
improving communication and the latter by educating or firing
people.

Do you advocate firing people that make mistakes?

IMHO introducing locks will only make life difficult to those
who know what they are doing and follow the rules.

ONLY !!! I don't think so.

Those people
usually are the ones that you absolutely do not want to piss
off (ie. the good employees).

Good employees see the value in locks.

 

[Antti S. Brax]

The reason for the freeze is to allow time for final test. If you
allow changes, the testing has to be done over.

That is why I mentioned branches.

I haven't had the luxury of working in a place that can afford
completely halting development for months. When a product goes
into a feature freeze it is branched and development on the
main branch goes on while the release branch is being tested.

Yes, but if the official 'company' position is 'xyz' it is necessary
to be able to tell customers that the company position has been
maintained independent of any last minute 'mistakes'. Did you ever
check in a file that had a bug in it?

Having locks is not enough to convince a customer (at least if
I am the customer). After all, I haven't seen a VCS where you
couldn't force the release of a lock. If you need to prove the
customer you need to show change logs of files even if you have
locks.

If you read the book about the development of WIN NT you will see
that MS did not allow changes during the final test interval.

"Allowing changes in the last month" and "having locks" really
do not have anything to do with each other. You can have changes
whether or not you have locks and vice versa.

Also, Windows NT is not really something you can compare any
other software project with. That was one of the largest and
most ambitious software projects ever made. Comparing the best
practises between "multibillion" and "mere million" software
projects is off topic for this thread but I say that it is
silly to suggest that people who work on smaller projects should
restrict their way of work because "NT was done differently".

Do you advocate firing people that make mistakes?

Even after realizing the obvious risk of throwing you on a
hyperbole, I will still answer "yes" to this question.

 

[Scott Ellsworth]

Hi
In cmomerical software house, i haven't seem several programmers
edit the same source file, right?

Multiple developers working in the same file is far more common than the
alternative, whether you are working an C++, Java, or Objective C. IME,
of course.

Actually bussiness company want to
prevent multi-programmers edit the same source file, but CVS doesn't
provide this function, it focus on "multiple edit", so that why
bussiness company don't use CVS.

Far more businesses I know use CVS than any of the alternatives. I have
seen some motion towards Subversion, but relatively little towards VSS.
Primarily because VSS is a pain to administer, IME, unless you are using
only MS tools, and that is not the environment we see.

the development method of CVS is "copy-modify-merge", VSS is
"lock-modify-commit". CVS guy say "lock-modify-commit" is a desuete
method, but they forget this is what business company do.

There has been considerable resistence to lock-modify-commit at the
companies I have been at. I have known a few, though, where a key
developer does want editorial control of the source, and uses
lock-modify-commit. At every one of those, the developers had their
own, private, VCS systems, and when they got permission to
lock-modify-commit, they would do so by checking their code out of their
private system and into the blessed locking one.

Scott

 

[Daniel Dyer]

Far more businesses I know use CVS than any of the alternatives. I have
seen some motion towards Subversion, but relatively little towards VSS.
Primarily because VSS is a pain to administer, IME, unless you are using
only MS tools, and that is not the environment we see.

I agree, all of the companies I have worked at previously used CVS. One
was using Source Safe and "upgraded" to CVS.

Visual Source Safe is also insecure by design, much more susceptible to
repository corruption than the alternatives and is just about unusable
remotely (very flakey with a VPN even on broadband). Not to mention that
it is Windows-only, which may be fine for Microsoft shops but that
restriction isn't very welcome for Java development.

To be fair, CVS has a number of problems of its own, which is why
Subversion exists, but it is infinitely preferable to Visual Source Safe.

There has been considerable resistence to lock-modify-commit at the
companies I have been at. I have known a few, though, where a key
developer does want editorial control of the source, and uses
lock-modify-commit. At every one of those, the developers had their
own, private, VCS systems, and when they got permission to
lock-modify-commit, they would do so by checking their code out of their
private system and into the blessed locking one.

Locking becomes a problem as your team gets bigger, and there will always
be occasions on which two developers need to modify the same file. The
key with the CVS model is to do updates as often as possible, even if you
are not committing changes.

Dan.

 

[Dotty]

Multiple developers working in the same file is far more common than the

alternative, whether you are working an C++, Java, or Objective C. IME,
of course.

Sounds like you need to refactor.
Why is it necessary to have multiple developers working on the same file.
Is your application all in one file?
Have you heard about ownership? Responsibility?
When you do testing do all of these folks show up?

 

[Scott Ellsworth]

Multiple developers working in the same file is far more common than the
alternative, whether you are working an C++, Java, or Objective C. IME,
of course.

Sounds like you need to refactor.[/QUOTE]

Perhaps. Or not. Refactoring, like a lot of other choices, are up to
the individual developers, and get done as the developers, or their
managers, notice problems justifying the work. Code smell is a real
thing, but fixing it, like everything else, has to be weighed in the
context of the overall problems we are trying to solve. Short source
files just does not buy that much.

Why is it necessary to have multiple developers working on the same file.

Some classes provide functionality for many applications. Developers
working on those applications may customize at the app level, or they
may push a fix or generalization up into the core library. Contrawise,
if functionality in a library is no longer used by more than one app, it
may get pulled back down into the app, or expunged entirely.

If more than one developer does this at the same time, then the same
file in that library may well end up modified by more than one person.
Particularly if they are changing interfaces that many classes implement.

Is your application all in one file?

Amusing. We deliver over a hundred applications spread over a hundred
and fifty jars, with over 6200 files of java source.

Have you heard about ownership? Responsibility?

Yep. Heard a lot about them, and have given them much thought in light
of an industry whose dwell time is under two years at a given job. I
suspect we have wrestled with these issues more than many, given a very
active team, lots to do, and rapidly changing scientific data analysis
needs.

When you do testing do all of these folks show up?

Testing, like everything else, is done based on how the managers driving
the projects prioritize it. There is interest in unit testing, and some
does get done, but in the main, integration testing gets the most effort.

Libraries get the best testing, as it is quite bad mojo to break a
library that others depend on. Applications meant for less skilled
users also get quite a bit more testing, as do those that change core
data. All of this happens in parallel, and people take a fair amount of
care to keep things working.

Scott