[EMAIL PROTECTED] on 2000.07.20 07:44:23
>Maybe we don't understand each other properly.
>
>I've mostly used CVS through WinCVS. The default WinCVS setup uses
>watches, wihich requires that you use "edit" to make the file writeable
>before you edit it (all files are read only after checkout). "unedit"
>reverts the file to the state it had before the "edit" command (the last
>revision on the current branch in the server's database).
>
>I really don't understand your claim that ""cvs unedit" never reverted
>the file back to the original version.". It certainly does so when I
>use WinCVS. The CVS manual confirms that the behaviour I descirbed
>above is the correct and expected "update" behavior when watches are in
>use (as they are by default with WinCVS).
I see. WinCVS wraps around CVS to hide this behaviour. I'll give you
an example using command lines:
cvs co module
cd module
chmod +w file
echo hello >> file
cvs edit file
echo goodbye >> file
cvs unedit file
# file will still have "hello" tagged to the end of it
The reasons why this happens are:
1. "cvs edit" and "cvs unedit" are supposed to work offline.
2. Since "cvs unedit" is supposed to work offline, it cannot retrieve a
copy from the repository.
3. Therefore, "cvs unedit" relies on "cvs edit" to save a copy in CVS/Base.
4. Since "cvs edit" is supposed to work offline, it saves the current local copy
in CVS/Base.
The documentation is dead wrong. Instead of complicating the documentation (by
describing that "cvs unedit" will revert the file back to the copy at the time
of "cvs edit"), it's much easier to simplify both the documentation and the code
(by saying that "cvs unedit" doesn't unmodify code).
>You change will break this behaviour and make the behaviour of
>edit/unedit asymmetrical, in that sense that unedit will no longer undo
>the changes made by and after the edit command. Besides removing the
>file from watch lists, this is the only propuse of unedit and changing
>it the way you describes seems like a bad idea to me.
Since WinCVS wraps around CVS, it should be changed to maintain its current
behaviour.
>Could you elaborate what you mean is wrong with the current unedit
>behaviour (besides the creation of files in the Base-folder)? I've
>heard you argument that minimal is good. Generally speaking that is
>true, but this new behaviour seems a bit too minimal for my taste...
See above.
>You see, one of my worries is that if unedit does not revert to the
>original file, then the user is removing himself from the watch list but
>he/she is still editing the file, since the local copy is different from
>the one on the server, and this changed file will probably still be
>committed later if the user does a recursive committ from a higher
>level. This will seriously break the fundamental logic of the watch
>lists. Seems like a bad idea to me.
This is why I posted a "cvs ci -c" patch that makes sure the user committing
the files has valid edits on them.
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.
