>--- Forwarded mail from [EMAIL PROTECTED]
>[EMAIL PROTECTED] wrote:
>>
>> Kate Ebneter <[EMAIL PROTECTED]>:
>Well, I believe that the result would be enormously bloated and
>unwieldy, and would not benefit anyone, particularly, given that there
>are plenty of other version control systems that work the other way.
>Indeed, if you have a cvs repository that you suddenly decide you want
>to use locking on, well, just revert back to rcs, and hey presto! Locks.
>Or vice-versa.
>CVS was implemented to solve a particular problem: How to do concurrent
>development. RE-adding locks (for that is what it would be) is a symptom
>of people attempting to use the tool for something it wasn't intended
>for. I'm not sure why this occurs, by the way. It is, honestly, not
>unlike complaining that your assembler doesn't understand C! I don't
>think anyone would do that, and I don't quite understand why people
>choose to adopt CVS without understanding the concurrent development
>paradigm. The watches and edits in the current implementation of CVS are
>intended to be used judiciously in situations where merging is difficult
>or impossible OR where, for some reason, the developer wishes to
>DELIBERATELY curtail concurrent development on a file or files.
>Communication is essential in such a situation, of course, as it is in
>all concurrent development (hell, in all development).
>Please, really, I'd really like to know why, if you want to do
>serialized synchronized development using locking, you chose CVS in the
>first place? There are many, many other suitable tools, many of them
>just as free as CVS, that implement that paradigm perfectly well. And
>there are many situations in which that is appropriate. But please,
>consider: Why choose a hammer when what you want to do is drive a
>screw?? And, why try to insist that there should be a tool that is both
>hammer and screwdriver?
The simple answer to your question about "why do people want locking
in CVS" is that they prefer the concurrent model, but can't use it
for all of their sources. In other words, they've found a need to have
both methods at their disposal in the same project.
As for the other stuff like reverting to RCS or SCCS, well, it turns
out that CVS has one incredibly nice feature that those simpler systems
don't: A centralized repository.
As for bloat and unwieldiness, that's in the eye of the beholder.
Every piece of software has features that are not used by some its
users. That does not necessarily mean that it's bloated. And there
has been a fair amount of discussion about how to implement locking
in such a way that they integrate very well with the command structure
and everyday use, so the operation of CVS remains familiar even when
applied to files for which locking is required.
>--- End of forwarded message from [EMAIL PROTECTED]
