info-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: CVS - setup reserved checkout


From: Thornley, David
Subject: RE: CVS - setup reserved checkout
Date: Fri, 12 Oct 2001 09:35:58 -0500

> -----Original Message-----
> From: Bryon Lape [mailto:address@hidden
> 
> The benefits add up to zero.  Now, if it did method locking, 
> that would be helpful,
> protective AND productive.  Without some sort of locking, 
> having developers waste
> time with doing merging by hand is counterproductive.
> 
What do you mean by "method locking"?  Locking individual parts
of a file?  It wouldn't do you any good.

If you are getting large amounts of conflicts with CVS merging,
that means that multiple people are changing the same parts
of files in different ways.  If the changes were localized in
the files, so that different developers would be locking different
member functions, then CVS would merge the changes just fine.

In my experience, with some sort of locking developers waste
time doing merging by hand.  Developer A is adding a feature,
and a bug report comes in from the field so developer B is
assigned to fix it.  B is now trying to hurry A up so she
checks in and releases the lock, which means that A is likely
to skimp on unimportant things like testing.  Assuming B has
not simply been playing 5,235 games of Minesweeper while waiting,
B has likely figured out how to fix the bug, and then finds that
A has modified that section and so he has to redo the bugfix.
(Of course, if A did not modify that section, CVS would work
just fine.)  Alternatively, management yanks the lock away from
A and gives it to B, who fixes the bug and checks in, and A now
has to do the manual merging.

Since merging of some sort is necessary when you have more than
one person (or, in some cases, one person with more than one project)
working on the same file, it's useful if the version control system
actually has facilities to assist with the merge.  Given that,
it makes sense to allow concurrent development.

You claim that the benefits are zero, in spite of the fact that
many, many projects have found them to be great.  It's pretty
simple, really.  If you have developers all over the place, changing
everything in sight, then CVS isn't going to help you, but neither
is anything else, because your shop is thoroughly messed up.
If you have developers working on specific projects that change
specific parts of the code, even if scattered among several files,
then CVS is going to help you.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]