Greg A. Woods wrote :
|| [ On Friday, February 11, 2000 at 18:47:50 (-0500), John Macdonald wrote: ]
|| > Subject: Re: CVS File Locking
|| >
|| > Greg A. Woods wrote :
|| > || [ On Friday, February 11, 2000 at 11:52:42 (-0500), John Macdonald wrote: ]
|| > || > Subject: Re: CVS File Locking
|| > || >
|| > || > Is there a tool that provides both concurrent version control and
|| > || > locked version control?
|| > ||
|| > || How could there be? It sounds like a direct contradiction of goals to me.
|| >
|| > When a file is created it would be given an attribute that specifies
|| > whether locking is required to change the file.
||
|| Ah ha! You said "file". CVS operates "simultaneously" on collections
|| of files. How do you propose to merge changes from one branch to
|| another when one of the files in such a collection happens to be
|| un-mergable? (don't bother answering -- it doesn't matter)
If a file in your work area is locked, you may not succeed with an
update request that would require the file be changed - any change in
the repository is a conflict (and no such change would have been
permitted to enter the repository in the same branch, because of the
lock). When you merge one branch with another, there is a conflict
unless one of the merged versions is identical to the common
ancestor. Resolving conflicts when you merge separate branches will
still be required; locks can only prevent conflicts within a single
branch but that can still be a valuable gain.
|| Yes I have suggested in the past that CVS could treat separate modules
|| as either mergable or not.
File, not modules. The (god forbid) MS Word documentation that has
to acompany each module, or the jpeg icon for the module, etc. The
few binary files that are a part of the module. Making them a
separate module ensures that they are poorly maintained.
|| However I've also pointed out that doing so would be in direct
|| contradiction with the goal CVS has of forcing developers to live with
|| concurrent development.
But you refuce to permit 99% concurrent along with 1% locked, forcing
100% locked instead. That disenfranchizes the converts, and prevents
any further preaching to the skeptics.
|| Furthermore I and others have pointed out that adding this kind of
|| dichotomy to CVS would turn it into bloatware unnecessarily. (In answer
|| to that I and others even suggested having a 'SVS' sister tool that
|| would share a repository with CVS and each would be taught to avoid
|| working on the other's modules.)
||
|| If you want to do hard locking on one or more files then do it somewhere
|| else with some other tool (bare RCS, SCCS, etc. are obviously fine for
|| just a few files) and learn to do release management in a way that will
|| help you keep these two separate groups of files in sync.
||
|| In the bigger picture it's just not necessary to compromise CVS in any
|| way w.r.t. concurrent development. I don't care if it can be done -- I
|| don't want it to be done. People who want hard locks *must* go
|| find/write some other tool and that's all there is to it.
I ask again, is there any alternative that permits both concurrent
development for the 99% of cases in which it works while also
providing locked access for the remaining parts where it doesn't?
Or is "go to another tool" really saying "give up on concurrent even
though it is vastly better for almost everything you do".
--
Anyone who can't laugh at himself is not | John Macdonald
taking life seriously enough -- Larry Wall | [EMAIL PROTECTED]
