>--- Forwarded mail from [EMAIL PROTECTED]
>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
>|| > || >
>|| 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.
Given the inclusion mechanism in the modules database, it would be extremely
difficult to enforce a per-module locking policy anyway.
>|| 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.
People contributing to this thread have complained that using bare RCS
(via "cvs admin -l") is completely inadequate. We all know why: It
was thrown in for completeness with respect to having the entire RCS
command line available to the user. No part of the "cvs admin" command
was ever intended to be a first-class feature.
>|| 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".
The message that comes across from you, Greg, is that users must choose
either the concurrent model or the locking model, and commit to it 100%.
If that simply isn't feasible, then they should adopt some difficult
hybrid environment.
But some of see all of these options as unacceptable; we want the world,
in the form of a version control tool that supports both methods where
appropriate. It so happens that, as featues are added, they can be
ignored as desired. That does not detract from their power or usefulness
for large numbers of users.
>--- End of forwarded message from [EMAIL PROTECTED]
