Re: After removing and (re)adding file is deleted without warning

[andyreifREMOVE_IT]

Jim.Hyslop wrote:
[...]
> Instead, how about adding a flag to the add command, to indicate that the
> user intends to "undo the remove". That would simplify processing (CVS
> wouldn't have to check timestamps), and allow both user scenarios without
> having to guess the user's intent.
> 
> The error message you posted earlier:
> > cvs add: file.txt should be removed and is still there (or is back again)
> would become something like:
> 
> cvs add: file.txt has been scheduled for removal. Use the -r flag if you
> intend to cancel the removal.
> 
> So, for scenario 1 (the one you originally posted, in which the user meant
> to re-add the file) the sequence would be:
> $ mv file.txt newfile.txt
> $ cvs remove -f file.txt
> $ mv newfile.txt file.txt
> $ cvs add file.txt
> cvs add: file.txt has been scheduled for removal. Use the -r flag if you
> intend to cancel the removal.
> $ cvs add -r file.txt
> 
> and for scenario 2 (the one I mentioned above):
> $ cvs remove -f build.log
> $ cvs add build.log
> cvs add: build.log has been scheduled for removal. Use the -r flag if you
> intend to cancel the removal.
> (at this point the user says "Doh!")
> $ cvs add build.txt
> $ cvs ci -m"Instructions on how to build this thing" build.txt
> 
> Thoughts?

Yes, some kind of flag
-r re-add/cancel the removal?
or e.g.
-f force addtion after removal
would at least partially solve the problem, but only for an attentive user.
And actually as info cvs says:
"   If you execute `remove' for a file, and then change your mind before
you commit, you can undo the `remove' with an `add' command.

     $ ls
     CVS   ja.h  oj.c
     $ rm oj.c
     $ cvs remove oj.c
     cvs remove: scheduling oj.c for removal
     cvs remove: use 'cvs commit' to remove this file permanently
     $ cvs add oj.c
     U oj.c
     cvs add: oj.c, version 1.1.1.1, resurrected"
it should work without any options anyway. Perhaps we have an outdated version 
(Concurrent Versions System (CVS) 1.11.1p1 (client/server)) at our university 
computers?


We still have the problem that if some file is 'cvs remove'd locally it will 
be removed regardless of the fact that it might have been changed.
There are actually 2 possibilities for the file to be changed:
1. before cvs remove
Since the 'cvs remove file.txt' doesn't work as long as the file is there,
user tend to use 'cvs remove -f'. Problem: user has to check manually if the 
file.txt has been changed. Wouldn't it be nicer if 'cvs remove' would work 
(and delete local copy, too, if it is invoked with a filename) as long as 
file.txt is unchanged (local test on timestamps)? If file.txt has not been 
changed and then deleted by accident, it could be easily regenerated by 'cvs 
update'.
'cvs remove -f' would then be used to force deletion, i.e. I know I have 
changed the file and do not want to keep neither the changes nor the file 
(and I do not want to hear any complaints, since I use a force flag).

2. after cvs remove
We have a remove timestamp in CVS/Entries. If file.txt is recreated after that 
timepoint we should regard it in special way when 'cvs commit'ting 
(regardless of the option that was used in 1).
Either 'cvs commit' should stop and say the same thing that 'cvs remove' 
currently says:
  file.txt still in working directory
  1 file exists; remove it first
or
  it should at least backup those files with .# prefix as this is done during 
merging.



Offtopic: wouldn't it be nice if the mail archive 
http://mail.gnu.org/archive/html/bug-cvs/ would have some button/link to 
reply to the mailing list? One then wouldn't need to subsribe to it to allow 
proper indentation of the own messages.