Re: interesting CVS problem

[Larry Jones]

Fran Fabrizio writes:
> 
> 1.  A user had checked in a bunch of images without -kb, and thus the
> images were corrupted when I tried to view them after checking them back
> out.
> 2.  I told the user to delete the images from his working directory,
> then use cvs remove to remove all of them, and then commit.  Then, add
> back in clean versions and commit again.

This was unnecessary.  What you should have done was to have the user do
``cvs admin -kb'' on those files to mark them as binary in the
repository, do ``cvs update'' in their working directory to pick up the
binary flag, copy clean version into the working directory over top of
the corrupt ones, and commit.

> 4.  I then checked out the project (images included) and 'rm *.gif'
> followed by a cvs remove <filename>.gif for all files (by the way, is
> there an easier way to remove 20+ files than having to rm them from the
> filesystem first and then enter all the individual filenames on a cvs
> remove command?!)

Yes -- "cvs rm -f".

> 5.  While I was 'cvs remove'ing files, I got a conflict, saying that
> 'another user has modified deleted file foo.gif.  Conflict created.
> Please resolve...yada...yada".  Only, foo.gif was no longer in my
> working directory.  I would do a cvs update foo.gif and it would say
> "conflict...please resolve..." but still no foo.gif reappeared in my
> working directory.  So I had no way to even attempt to resolve the
> conflict. (which would have been impossible on a binary file anyway, but
> it brought up the general issue of "if I rm a file and then try to 'cvs
> remove' the file and another user has modified it, why can't i get it
> back to resolve conflicts and then finish removing it?)

You just need to use "cvs add" to resurrect the deleted file.

-Larry Jones

I obey the letter of the law, if not the spirit. -- Calvin