Why does rcs co on ,v files create 0kb files for some?

Question

OS and tools info: I am using most recent (2/11/2015) updates of Cygwin's mintty Unix bash on Windows 7.

I am working to convert a CVS repository to use Git and need to recover the files from a tarball. After extracting the files, I have tried using "cvs checkout" and that has gotten a few of the files, but a majority of the files are in Attic directories and were not checked out, even when I moved them all up one directory so they were not in Attic as was suggested in this gnu forum After this did not work, I tried cvs2svn which would not resolve. Finally I tried using regular RCS co, which created most of the files I needed.

However, all of the converted files from Attic sub-directories in one top-level directory were empty (0kb). Even when the ,v files were moved to higher levels, they did not extract properly.

Code (rcs co working as it should for the following)

$ pwd
/tmp/test/repo/<working-directories>/
$ find . -type f -wholename "*Attic/**,v" -exec rcs co {} \;
$ find . -type f -name "*,v" -exec rcs co {} \;

$ cd /tmp/test/repo/<trouble-directory>
$ find . -type f -name "*,v" ! -wholename "*Attic/**,v" -exec rcs co {} \;

However, rcs is not working as it should for the following command and creates files of 0kb size

$ pwd
/tmp/test/repo/<trouble-directory>
$ find . -type f -wholename "*Attic/**,v" -exec rcs co {} \;

Moving to the top-level did not work

$ pwd
/tmp/test/repo/<trouble-directory>
$ find . -type f -wholename "*Attic/**,v" -exec mv {} . \;
$ find . -maxdepth 1 -type f -name "*,v" -exec rcs co {} \;

Even moving to the working directories did not work

$ pwd
/tmp/test/repo/<trouble-directory>
$ find . -type f -wholename "*Attic/**,v" -exec mv {} ../<working-directory> \;
$ cd /tmp/test/repo/<working-directory>
$ find . -maxdepth 1 -type f -name "*,v" -exec rcs co {} \;

What could explain this behavior of rcs co? The other files are of similar size and extensions. I can't seem to find anything in the documentation of the repository to treat the Attic files in this particular directory any differently and I haven't been able to find a smoking gun in any configurations. Any ideas?

Answer 1

Some developers check-in a zero-sized file to indicate that it has been deleted. Alternatively, they could have relied on version labels and omitted the file from that label.

If that is what was done, rlog will show the change (and often with a comment saying the file was deleted).

Additionally, a script can be written using the tip/head version shown by rlog to count back one revision and obtain the last non-empty version of the file. That is more complicated, of course -- but since the question is why, rather than how to, a suitable script would be a separate answer.

Answer 2

The reason for files being in the Attic is that they were removed or somehow otherwise unavailable. The latest revision of such a file could reasonably be represented with an empty file, or no file at all.

If you want to retrieve an earlier version from the Attic, I suppose you could; but then, you are introducing an inconsistency in the history of the project.

I have little experience with git cvsimport, but that's the first thing I would try if I were you. It's not like you are the first person to want to migrate from CVS to Git.