Hi Tobias,
>The "locks" current available due to 'cvs admin', are an artifact due to
>the
>RCS backend that CVS was first built on. CVS was meant as a tool to manage
>a collection of RCS files, with certain ways of dealing with conflicts.
>The
>'cvs admin' collection of commands were a *DIRECT* interface to the RCS
>backed.
>
As a purist, you should be waking up in the middle of the night with the
scream: "Lock, Locks everywhere!" ;) That is how it works - watch how many
times the first question from the new users posted to this list is: How do I
lock the stuff? And, guess what happens next - they are told to read the
manual. They do. They search for 'lock' keyword. They find "cvs admin -l".
At this moment they scream "Eureka!" and happy ever after "dumb-lock" every
single file, with the strange impression that these locks seem to promitive.
But it is the free software, so what the heck.
This is death of concurency. And it is said :(
I would like to see this stop happening. I want the locks to be hard to turn
on, and difficult to maintain. I was even considering to put a piece of code
which would randomly (with ratio 2/1) generate the error during locking just
to discourage it :)
>One of the repeated things that keep coming up, both here on the list, and
>in
>the manual(s) is that the RCS backend should/could be replaced sometime.
>Maybe
>with xdelta type stuff. At that point, and maybe sooner, the 'cvs admin'
>hook
>to the RCS locks (which 'cvs admin -l' are) will go away.
I don't see it happening. CVS is being trade-off, it doesn't help.
>I'm telling you there are better ways to handle your VB files.
Maybe, but my VB files is only an example. I want a generic solution.
BR,
Jerzy
The first thing they don't teach you at school: "Never say never".
All the issues not related to the list please send to me in private, thanks.
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
