[EMAIL PROTECTED] on 2000.07.21 14:12:25
>> 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.
Saying that CVS has zillions of flags is hyperbole. If you want to see what
zillions of flags is, look at ClearCase.
The interface to CVS with my patch is: "cvs edit" will save a backup using the
standard naming conventions for backups. "cvs unedit" will not modify the
existing file. This is an extremely simple interface.
If flags were added, there'd be a few unlesses for the "cvs unedit" interface.
It'd be more complicated.
>> 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!
If so, those side effects are highly documented and consistent (ie they're not
side effects).
> The chance that something actually happened to the backup are quite
>small, and could be detected for example with the time-stamp.
No they can't. What part of "\"cvs edit\" saves a copy of the file the way it
was at the time of \"cvs edit\"" don't you understand? Or, can you explain how
you'd go about using timestamps to figure out if something has happened to the
backup?
>Also, making a
>backup read-only would solve about 99% of the problem.
I think I already do this, but I'm not sure. I don't think I'm opposed to doing
this.
>Additionally backup
>name could be changed so it doesn;t look like the original file and thus it
>is easier to detect mistake.
The backup is meant to look at least a little like the original so the user /is/
able to use it. All I do is use the standard file backup routine. If you want
to change that, that's fine by me (so long as the new name is still easily
computable from the original name).
> 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.
See above with regards to write bit.
Where is the timestamp recorded? In any event, this'll complicate the code a
lot. If someone else wants to do it, they can.
> 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
I'd like to keep backup filenames consistent among the commands. In all, I like
the idea of having the revision as part of the backup filename. Something like
.#foo.c.2.12 would be good (although it should be very rare that you see a major
revision number other than 1).
>2. During unedit:
> a) check if there is a connection to the repo. if it is then attempt to
>get the revision from repo.
I haven't been able to figure out a way to see if there is a connection or not.
Perhaps someone can help out here? I've seen other occassions to know the
connectability status.
> 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:
The most you can check (with your timestamp scheme) is whether the file has been
modified sometime after the "cvs edit". You won't be able to see if the file
has been modified between "cvs co" and "cvs edit".
> 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.
This would make "cvs unedit" interactive (ie non-batchable). This was one thing
I removed on purpose. Maybe it should just error out (atomically, of course, so
that no other files will be uneditted).
Connecting to the repo at this time may be impossible with the current
architecture. Then again, I'm not too knowledgable about this part of the code.
>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.
Both keep and revert will need flags (so people can override what's in their
.cvsrc files).
>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.
I did it right (at least for my needs).
If you feel otherwise, don't use my patch (or patch it up some more).
Seriously, though, none of the others have jumped in 'cos they don't use "cvs
edit" and "cvs unedit". I think I'm the only one who does who also wants to
maintain the CVS philosophy of keeping the tool simple.
>From what I've seen in the past, you seem to have been hacking WinCVS. If this
is true, you should be able to easily (since the interface is so simple) hack
WinCVS to do most of what you want.
Noel
This communication is for informational purposes only. It is not intended as
an offer or solicitation for the purchase or sale of any financial instrument
or as an official confirmation of any transaction. All market prices, data
and other information are not warranted as to completeness or accuracy and
are subject to change without notice. Any comments or statements made herein
do not necessarily reflect those of J.P. Morgan & Co. Incorporated, its
subsidiaries and affiliates.
