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

[Mark D. Baushke]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Patton, Matthew E., CTR, OSD-PA&E <address@hidden> writes:

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

There is indeed a basic problem with how the -kb flag works across all
versions of a file which is unfortunate. Fixing that problem by adding
an RCS format extension to keep track of it on a per-version basis might
be accepted as a patch when submitted to address@hidden

> 'cvs remove' doesn't delete the ,v file but just moves it into Attic.

Actually, 'cvs remove' on a branch will not even move it to the Attic.
The Attic is an optimization for things on the mainline that is often
more trouble than it is worth.

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

Close, it will not add your new contents to the ,v file until after you
do a 'cvs commit' operation, but if the ,v file was in the Attic and
your 'cvs add' was to the mainline, you will indeed observe the behavior
you mention when you do a 'cvs commit' after doing a 'cvs add' to revive
a 'dead' file.

Files are NEVER removed from the repository.

Just because you do a 'cvs rm' on them, does not imply that they did not
have valid versions in them for some period of time. 

A 'cvs remove' implies that the top version in a particular branch has
been removed. The file may be alive in other branches or may be
resurected via a 'cvs checkout -rsome-tag' or 'cvs checkout -D"5 January
2001"' command at some future date.

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

I suspect a closer reading of the manual may have helped to eliminate
that surprise, but if not, please feel free to submit suggestions for
how to make things clearer.

> IMO this is uncalled for "help" from CVS that is actually very
> unhelpful.

Your opinion does not match the expectations of many years of use for
the operation of the program as well as its documented behavior.

> Much like Microsoft keeps trying to be helpful and being anything but.

Hmmm... I am not a fan of Microsoft products. I much prefer open source
so that if I don't like the way something works, I can create my own
version of it.

With cvs, you have the ability to hack your own copy of it to do
whatever you feel is desirable, just don't expect that your changes
will always be adopted by the maintainers.

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

Are you reporting a separate bug where you have lost data due to a file
bein resurected? If so, please identify the version of cvs you are using
and give a bit more details as to how you lost the data due to an
overwrite.

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

I disagree with your opinion.

There has been talk of removing the concept of the Attic in the past,
but actual removal of the ,v files has never been and will not be a part
of the baseline version of how cvs works.

> Somebody might have had the notion at some point that this "unremove"
> functionality was useful. If it is, then let's implement it properly.

It is already correct modulo the per-version desirability for some
attributes to also be maintained such as the keyword expansion and the
permission bits.

Over time, various versions of the file existed for some period of time
and this is a source control system that lets you find the state of the
repository at a particular given point in time.

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

Feel free to use another system or to hack cvs in a way that makes you
happy.

        -- Mark
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (FreeBSD)

iD8DBQFAUm0L3x41pRYZE/gRAkbzAKDStFx6wgeMoUy+9ztpBM8Mp0W0YwCeI0RT
gt0g9pWPV5yBNJGrjskCTGQ=
=wYZZ
-----END PGP SIGNATURE-----