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

[AndreasReifschneider]

I wrote:
> 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"

Oops, it actually works like that, but only if the file oj.c is not recreated 
in the meantime.

> 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

better: ... as file.txt is unchanged (local test on timestamps) or already 
deleted? ....

> been changed and then deleted by accident, it could be easily regenerated
> by 'cvs update'.

And this wouldn't break the current behaviour (at least not in an unexpected 
way)?

> '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).

Looking at timestamps is in fact the wrong way. We just should look at the 
existence of files that were scheduled for removal but somehow reappeared.

> 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.

This is the _actual problem_ to be solved.