Classification: UNCLASSIFIED -kb or not, I think this brings up what amounts to a bug or yet another instance of "surprising and unexpected" behavior which needs to be killed.
'cvs remove' doesn't delete the ,v file but just moves it into Attic. Unfortunately when you 'cvs add' a file that has the exact same filename CVS "helpfully" moves the ,v out of Attic and then appends/modifies the ,v to incorporate the newly added file. This ascii/binary thing is directly attributable to this. It also surprised me when a file I thought had been killed off suddenly came back with a whole revision history attached because the filenames collided. IMO this is uncalled for "help" from CVS that is actually very unhelpful. Much like Microsoft keeps trying to be helpful and being anything but. I submit that we alter the code so that if there is a name collision in Attic that CVS does NOT try to be "helpful" but always overwrites the file. And furthermore files in Attic should be inserted only, NEVER pulled back out unless a human directly manipulates the repository by moving the ,v file back into said repository. Somebody might have had the notion at some point that this "unremove" functionality was useful. If it is, then let's implement it properly. Getting my file back after I've removed it from the repository by 'touching' the file in a working directory and committing it is just plain nuts. _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
