On Sunday, February 13, Tom Satter wrote:
>
> With regard to your statement about logical arguments, take
> two of the issues that are currently being discussed:
>
> 1) locking in cvs
Ok, I'm going out on a little bit of a limb here... All IMHO
of course...
If done (and I think that's a big if), it should be done by
completely scrapping the current model, and adding code to
'cvs lock' and 'cvs unlock':
cvs lock - Must be up-to-date
I don't particularly like the 'cvs edit' locking stuff being
talked about. I don't like overloading things, keep them
conceptually simple and clean. Under unix (or lookalikes),
typing can be reduced with aliases, and under WinCVS, or whatever
GUI you are using to access CVS, the two operations (checkout,
and locking) can be combined in a dialog box...
> The argument that has very consistently been made is that
> the second part of the add request complicates the software.
This I agree with wholeheartedly. I've not said much about the
'cvs add' thread here, been thinking about it for a while now.
Anyhow, I'd like to see the following here:
'cvs add' and 'cvs remove' are not recursive (unless, maybe they
specify a directory). Also, I'd like to see 'cvs add' not add
directories to the repo until 'cvs commit' time. For this to
work, I don't see how any more traversals are necessary than
already done...
> p.s. I really do not care if Greg is busy or not. If
> he is so busy that he can't write a reply without
> losing his patience then maybe he should not write
> so many replies. And, I don't know why this is
> important, but I have also been using revision
> control systems for over ten years, longer if you
> are going to count using zip files as revision
> control.
Ouch, you have been around a while, eh? :-)
--Toby.
