RE: Can't change ascii/binary type of file

[Paul Sander]

>--- Forwarded mail from address@hidden

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

I don't think you've considered all the funny cases that come into play
when deleting/undeleting/branching files.

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

Historically, the file is moved to the attic to hide it from subsequent
checkouts on the trunk.  Now that removals are recorded as dead states,
that action is probably superfluous.

However, when a file is removed, that does not necessarily mean that
a) it's removed on all branches, and b) it's not removed from old
configurations that might later be retrieved by tag or datestamp.  For
these reasons, an RCS file can never be completely removed from the
repository.  And because the mapping between RCS files and their
counterparts in users' workspaces is primitive, the only option to
resurrect a dead path is to reuse an existing RCS 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.

The keyword expansion is (correctly) an attribute of the entire version
history of the file, not for specific versions.  So you can't fake out
changing formats of a file during its lifetime.  (Binariness is a type
of keyword expansion in RCS and therefore CVS.)

What you're asking for is a variation of versioned directories that I
have been pusing for for many years.  There should be a level of indirection
between the working file and the RCS file that allows paths to be overloaded
on different branches or at different times.

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

Nope, rou can never delete an RCS file from the repository.  That violates
the reproducibility requirement of any version control system that permits
the removal of files.

Some things that I think you're considering with this proposal:
- What happens the second time a file is removed?
- What happens to branches after a file is re-added, that is, once there's
  an RCS file in both the repository directory and the Attic?

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

Your points are all valid, but I think your proposal for the change in the
CVS design won't work.  Clean designs have been proposed that solve this
particular problem well, but in the best tradition of open source software,
no one has gotten around to doing it, yet.

>--- End of forwarded message from address@hidden