I'm not sure that this is strictly on-topic: since CVS supports both
methods quite well, and in fact even allows mixing the two, there's
not much to discuss in terms of the CVS design.
However, it is an interesting subject, so I'll just drop my two cents
quickly and then shut up. :)
On Fri, 31 Mar 2000, Bill Lee wrote:
> I have worked in closed environments for a long time using reserved checkout
> systems such as MKS, PVCS, and SourceSafe.
Ditto, although my experience is only with CVS and (shudder) SS.
> In this environment, where many
> people may be working on the same set of files, and often same file; where
> there are common programming disciplines and guidelines, I have found the
> reserved checkout scheme more reliable than merging. Merging, in my
> experience, by developers of a variety of skill levels has allowed hard to
> find bugs to creep in when conflicts are manually resolved or not detected.
Very much disagreed. I have used both methods extensively, and merging
rarely has caused me (or anyone else I know) any problems, while reserved
checkout results in many hours of lost productivity as the individual
programmers find their hands tied.
In my experience, if two pieces of code don't merge properly, it's because
two programmers were working on the *exact* same functionality, and just
wrote them differently. In this case you have a much larger problem
than anything revision control can help you with - you've got a communication/
leadership problem with your team.
> We allow simultaneous modification of files, but this was the exception. And
> branching projects allowed us to maintain older versions of projects while
> new development continued along the main "trunk."
Certainly taking advantage of branching is an excellent idea, but I think
that it goes hand-in-hand with nonreserved checkouts.
Adam
