Dear Noel,

> When I first made this patch, I decided for two reasons not to add "cvs
unedit"
> flags to revert or keep changes:
> 1. Flags complicate the interface to "cvs unedit".

?! What kind of argument is that? NOT having the flags complicates the
interface to cvs! Come on, all CVS commands have zillions of flags, why
unedit can't have...? Since flags are not compulsory, just helpful, the
argument of 'complication' can not stand.

> 2. The backup copy can't be trusted since the user can easily do something
to it
> now.  So, any modifications to the backup have side effects affecting "cvs
> unedit".

This is true, but the solution you propose seems to have even more side
effects! The chance that something actually happened to the backup are quite
small, and could be detected for example with the time-stamp. Also, making a
backup read-only would solve about 99% of the problem. Additionally backup
name could be changed so it doesn;t look like the original file and thus it
is easier to detect mistake. I think to add the revision number after the
filename (like the conflict does) would almost solve the remaining 1% of the
problem after making the file read-only.if you could make a patch that way:
1. During making a backup:
    a) the backup is created as read-only. Eventually the timestamp is
recorded to allow the detection of accidental modification.
    b) the backup name is the original filename + revision number instead of
the same name as original, eg. file foo.c is backed up as foo.c.2.12
2. During unedit:
    a) check if there is a connection to the repo. if it is then attempt to
get the revision from repo.
    b) if no repo connection is at hand then check if the original file was
modified, if it was then check if it backup was modified. give the choice
for the user:
        o do not revert
        o revert to the backup (with the warning if the copy is modified)
        o offer the attemp to connect to the repo.
3. unedit should have the flag to force the revert, the important part is to
not have cvs interact with the user so the shelling and scripting othe
unedit is possible and easy.

If you are attempting to solve the problems around edit/unedit then do it
right. Do not make patch which creates more problems than it solves. I seem
to not be alone in that feeling.

Best Regards,
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.

Reply via email to