Noel L Yap wrote:
> [EMAIL PROTECTED] on 04/05/2000 01:33:39 PM
[Let's prevent mistakes]
> This isn't a new definition, it's always been documented this way.
>
> Exactly which mistakes are you talking about? If it's the possibility of doing:
> cvs edit file
> # modify file
> cvs unedit file
> cvs ci # accidental commit of file's modifications
>
> I've already said that the current implementation in no way prevents this:
> # modify file
> cvs edit file
> cvs unedit file
> cvs ci # accidental commit of file's modifications
I hadn't considered this second case previously. I'm still not sure I think your
solution is best here, however, and the current implementation prevents mistakes in
the first scenario. I'll touch this again shortly.
> Also, the forth-coming "cvs ci -c" patch will help prevent these sorts of
> mistakes.
Nice. Maybe enough to prevent the unwanted checkins, but data loss remains
possible. See below.
[Old dogs want new users to have trouble committing by accident and committing
changes they didn't know the new users were working on. On a good team this helps
foster communication and leaves fewer messes to clean up.]
> Nothing in my proposal changes this. It's suggested that developers "cvs edit"
> the file before committing, but the tool cannot enforce this. Nor can the tool
> enforce when developers "cvs edit" the file.
No, but I think many people could treat a read-only file as a polite reminder to
use 'cvs edit'.
[Tougher to err, not impossible]
> >From your previous comments, you obviously understand that the intention of the
> tool (ie "cvs edit" and family) is communication. How does my proposal (for
> "cvs unedit" not to unmodify the working version of a file, but rather just to
> perform its real duties of communication) make it "much easier to misunderstand
> the intention"? I should make it clear that "cvs edit" will still make the file
> writable and "cvs unedit" will make it unwritable.
Okay, I WAS under the impression that not changing the files at all included not
changing their permissions. Also, we may disagree about the intention. Again,
I'll get back to this.
> So, given that the developer forgets to "cvs edit" and "cvs unedit" at the
> correct times, the second scenario above will occur with the current
> implementation -- what's the problem? CVS doesn't force anyone to "cvs edit" to
> begin with -- I still don't see what the problem is.
> I really don't understand your point. Can you please elaborate and preferably
> give an example?
First skipped point: I think the 'cvs edit' family of tools are communication
tools intended to make it tougher to edit shared files without communicating first.
Third skipped point: To further this intention, I think it would be preferable to
move in the other direction. i.e. Have 'cvs edit' print a warning or require a
'cvs edit -f' when it finds that the file to be edited has been modified. This
could possibly mean exhibiting this behavior just because the timestamp has changed
when offline. Also, make the 'cvs ci -c' the default behavior for a commit and
require a 'cvs edit -f' (as above. This could just print a warning but I think I
would opt for the strict case here - it prevents missing the problem when
recursing.)
Hmm. Okay, I think that's too strong (it might break wrapper scripts). I guess I
would find the '-c' flag satisfying, since it would allow configurability and get
most of these features, but I think I would still want the save/restore
functionality of edit/unedit. I would also want the "check for modification"
functionality I just mentioned added to 'edit -c'. I'll provide an example near
the end.
[Restore the version of the files that matches tags with other files in the
directory]
> The design of both "cvs edit" and "cvs unedit" is to allow offline work. IMHO,
> "cvs unedit" should not unmodify to the BASE revision (or to any revision for
> that matter). If, OTOH, one wanted to do such a thing (within CVS), I wouldn't
> know how to maintain the offline capabilities with consistently retrieving a
> BASE copy without a lot of overhead (eg keeping copies of all files around even
> before "cvs edit" is done) -- I think it's impossible.
Well, you would be limited to restoring either the modified initial version or
nothing in the case where everything took place offline. Once a single update
happened, however, it could be treated like calling 'update -C' on the Base
revisions.
[Track chmods instead]
> Not only this, but there're many times I "chmod +w file" instead of "cvs edit
> file" since all I'm doing is putting in debug code (in fact, using emacs, I
> don't even have to "chmod" any more). Again, "cvs edit" is a communication
> mechanism by which you tell others you plan to commit the changes you're
> currently working on. In fact, another idea I'm playing around with is to allow
> developers to describe their edit sessions (eg "cvs edit -m 'fixing bug 1024'").
> Given this, you wouldn't do "cvs edit -m 'putting debug printfs; dont intend to
> commit' file", would you?
My 'cvs edit -c' and your 'cvs ci -c' would seem to keep these kind of changes from
being committed easily.
[cvs unedit should back up file, thus preventing data loss]
> No, one more time, since the file isn't guaranteed to be clean (ie the developer
> modified the file before "cvs edit"), mistakes will still occur.
Again, my 'cvs edit -c' avoids this.
> OTOH, if "cvs unedit" never unmodified the file to begin with, there'd be no
> data loss at all.
['cvs unedit' not backing up requires manual backup to prevent data loss].
> Why would you need to back it up yourself if "cvs unedit" never changes the
> file? If you really did want to throw away your changes, you'd still have to
> "cvs up -C file" (or its more complicated counterpart) anyway to absolutely
> guarantee a clean copy.
I'm not sure about 'cvs up -C file', but 'cvs up -P file > file' doesn't leave any
backups sitting around.
['cvs edit' family are security and training tools as well as communication tools.]
> I still don't understand. My proposal does nothing of the sort. I'll spell it
> out again:
> "cvs edit" will create a backup of the file and notify watchers.
> "cvs unedit" will not unmodify the file while still notifying watchers.
> "cvs ci" will still commit modified files.
>
> As separate proposals/patches:
> "cvs edit -c file" will abort the edit if others are already editting file.
> (done)
> "cvs edit -f file" will force the edit of file. (done)
> "cvs ci -c" will abort the commit if a valid edit doesn't exist.
So, my proposal:
"cvs edit" will create a backup of the file in Base, chmod +w the file, and
notify watchers
"cvs unedit" will backup the file, restore the copy from Base, chmod -w the
file, and notify watchers
"cvs up" will update files in Base as "cvs up -C"
"cvs ci" will still commit modified files, chmod -w the file, and notify
watchers
And:
"cvs edit -c file" will abort the edit if others are already editing the file
or if the file is different from the version in the repository
"cvs edit -f file" will force the edit of the file
"cvs ci -c" will abort the commit if a valid edit doesn't exist.
I think this is consistent with all the scenarios you described, and, in
combination with '-c', users should end up with unwanted data checked in less
frequently. There is also still a backup sitting there (locally, I would think),
if you want the data back after an unedit.
Derek
Derek R. Price
CVS Solutions Architect
303.554.8291
[EMAIL PROTECTED]
http://alumni.engin.umich.edu/~oberon/resume.html
--
OK, who stopped payment on my reality check?
