[EMAIL PROTECTED] on 2000.04.08 20:11:12
>But the long answer is interesting:
>>Long answer:
>>I've come to think that the Base subdirectory is a broken design.
>>1. The copy stored in Base isn't really the version that was originally
>>checked
>>out, it's the version existing at the time of "cvs edit".
>>2. "cvs unedit" is interactive due to it's modification check.
>
>As to "1" I think it is OK. I think I want it to restore to the same point
>as before "edit". Wouldn't change that. This way also "Edit works without
>the server connection" in a way.
>As to "2" I see no problem. The problem is to me something that cause the
>loss of work, like editing the wrong file. Not the case here.
I guess the real problem I have with "Base" is its name. It's a misnomer.
What's stored in it isn't a copy of the Base revision, but what existed at the
time of "cvs edit". So, part of my proposal is to have "cvs edit" just create a
backup the normal way CVS does with some other commands.
The problem with an interactive "cvs unedit" is that "cvs release" is also
interactive. Worse still, the interactiveness is per file. Sometimes I'd like
to just wipe out an entire tree (somewhat like "rm -rf" with an unedit). I
suppose I could just to "cvs unedit; rm -rf" but that takes forever.
Also, being a Unix programmer, I don't like interactive tools (unless I make
them interactive) -- I prefer Unix's "rm *" over DOS's "erase *".
>>I propose to:
>>1. Have "cvs edit" create a backup of the file via the usual means (thereby
>>exposing the backup -- not hiding it within CVS/Base).
>>2. Have "cvs unedit" solely unedit the file(s) (and perform notifications).
>>"cvs unedit" would no longer unmodify the file(s) -- it would be up to the
>>user
>>to unmodify the file since he/she now knows where the backup is.
>>3. Get rid of Base (as it'll be unnecessary due to the previous).
>
>As for "1" I agree.
>Not quite sure about "2". Perhaps it could be smart enought to check for
>modifications and react properly(whatever 'properly' means).
I should've been more specific here. My proposal is to have "cvs unedit" make
the file read only, turn off the edit, and to notify other users. It will no
longer unmodify the file.
>As for "3" I agree.
>Just wondering:
>Noel, do you have the access to the CVS repository? If you would/do, you
>could fix quite a lot of things there (and get your patches go thru, which
>would make CVS a much better tool :)...
Although I think my CVS development skills have improved within the last year or
so, I still have a bit to go (I haven't mastered sanity.sh, yet). So, in a way,
I'm a little glad I don't have commit access to the CVS repository. I do wish,
though, that someone is at least looking through my submissions to include what
I think are the most important (ie "multiple edits per user per file" and "cvs
edit -c" iff it works "correctly" when the server isn't active). Thanks for the
vote of confidence, though.
Noel
