Cameron, Steve wrote :
|| Mike Little wrote:
|| 
||      [smc]  [...some good stuff deleted ] 
|| >  
|| > Keep CVS simple! 
||      [smc]  How can anyone disagree?
||      To disagree is to say "Make CVS complicated!" :-)
||      But I oversimplify.
|| 
||      For the file lockers out there, a question or two:
|| 
||      I gather you would like to be able to lock individual files 
||      on a per-branch basis, purportedly to prevent concurrent
||      editing.   Well, that implies you would like to concurrently 
||      edit the files...otherwise, why the need for _per-branch_ 
||      locking?  So which is it?  And then, when it comes time 
||      to merge the branches? What then?  Well, the files are
||      not mergeable (hence the locks) so I guess you just pick
||      one or the other and throw out the changes on one branch
||      or the other...Well, that's nice.
|| 
||      So maybe you would like to eliminate branching in order
||      to facilitate locking? 
|| 
||      Ok, these questions are mostly rhetorical I suppose, :-)  but
||      it seems any locking code written would have to address 
||      them in some fashion...

This will depend upon how people use branches.

I use the main branch for ongoing development.  A branch is made for
each release.  If a problem needs to be fixed, the branch for that
release is checked out, the fix made and tested, and a new variant of
that release is built.  The fix also has to be merged back into the
main development branch and possibly also into other release
branches.  Generally, though, there have been enough improvements in
the main development branch that we only build a fix release for
specific customers who are tripping over the particular problem and
need the fix right now; others get the fix as part of the next
upgrade release.

Having to deal the problems of merging for only those rare cases of
retrograde fixes, and being able to the possibility of concurrent
changes for development activities on the few unmergeable files is a
big win.  It changes cvs from being error-prone (by demanding that
users remember which few files need to being changed exclusively and
dealing with them specially while using the far more convenient
concurrent development for all other files).

-- 
Anyone who can't laugh at himself is not    | John Macdonald
taking life seriously enough -- Larry Wall  |   [EMAIL PROTECTED]

Reply via email to