[EMAIL PROTECTED] wrote:
>
> Kate Ebneter <[EMAIL PROTECTED]>:
> >
> > And as for locking, I'm sorry, but what part of CONCURRENT Versioning
> > System don't people understand??? If y'all wanna turn it into Control
> > Via Synchronization, well, could you please do it to another source
> > code control system? Please? There are TONS of very good source code
> > control/versioning systems using synchronization via locking. There
> > are very few that permit or properly support CONCURRENT development,
> > let alone make it the center of the development model. I _NEED_ CVS to
> > be a CONCURRENT versioning system. I don't need locks,
>
> I agreed with your post up until this paragraph, which seems to
> express a sentiment so common that I thought I'd offer some
> feedback from the newbie perspective.
>
> Let me ask: what is it about locking and concurrency that makes
> them mutually exclusive? Other software manages to find design
> patterns that allow them to handle configurable policies. (The
> X11 mantra "mechanism not policy" is a great example) Why not CVS?
>
> Why not let the repository maintainer choose their policy?
>
> It seems to me that nobody is asking the developers to consider
> changing CVS so that it no longer properly supports concurrent
> development. Aren't you misrepresenting their position when you
> suggest otherwise?
>
>
> Configurable
> Versioning
> System
>
> (think anyone would notice?)
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?
Kate Ebneter
Build Engineer and Rabbit Wrangler
DataRover Mobile Systems, Inc.
