Is there a tool for repairing RCS/CVS ,v files? [closed]

Question

I am doing a whole bunch of conversions of CVS and RCS repositories into Subversion. Every now and then I run into a damaged ,v file. I have figured out how to repair these manually, but it's getting tedious, and my latest project has numerous damaged files, more than I care to repair manually.

So I'd like to have a tool to parse the RCS files and repair them. That may well mean some old versions will be incomplete. For example I've seen cases where version 1.1 was missing, so adding an empty revision with a comment indicating that it's missing does the trick.

I have done many searches trying to find such a tool, but have turned up nothing. I was about to start writing my own tool, but thought I should try asking here, first.

I know I could just get code snapshots and import those, and I'll resort to that if I have to (just to head off those suggestions :)

++thanks

Goatish

What's the nature of the damage and how are you repairing it? – Marquittamarr

There is a variety of kinds of damage. The worst I am facing now is that portions of the ,v files are replaced with nulls (I am guessing a disk filled or they had a disk error at some point in the distant past). All I can do is replace the damaged revisions (which are always very old versions) with empty revisions indicating they were corrupted. It's no worse than what they have now. – Goatish

Answer 1

I personally do not recommend manual migration as the process is very time-consuming and there is no way to come out of it with a full data/metadata set in the resulting repo.

There is a tool for migrating CVS to SVN and it is called cvs2svn. It "is a tool for migrating a CVS repository to Subversion, git, or Bazaar". You can refer to this how-to for a quick start advice.

Check this out:

CVS was just a front end to RCS, and the *.v files are really RCS files. Just check them out. eg, if you have foo,v just execute:

co foo

and it will checkout foo from the ,v file.

Also there is an RCS to SVN converter and you can try that one too.

Bertiebertila

Yes, I am using cvs2svn. The conversion isn't the problem, the problem is that it chokes on the corrupted ,v files. Manually fixing them is a tedious and somewhat error-prone process and it seems it should be automated in some way. – Goatish

I've updated my answer, try that out. :) – Bertiebertila

RCS commands bomb on these files as well. A few of them are damaged such that rlog fails, but the remainder fail when I try to checkout the revisions where the damage is located. I wrote a script to run through all the ,v files running rlog and then co on each revision, which is how I know the damage is widespread. – Goatish

@trent, would you care to share your script I am having the exact same problems as I cannot get CVS to truncate the files in the repository (folders with ,v files). – Pankhurst

Answer 2

I wrote a Python library, editrcs, that parses RCS files into a tree that can be modified and then written out as a new RCS file. It is not designed to cope with invalid RCS files but could be a reasonable starting point if the corruption is only in the data sections or you modify the library to work around any corrupt metadata.

Also relevant to your particular question:

1. RCS files store the latest revision of the trunk and diffs going backwards on the trunk. So if the diff for a historic revision is irretrievably corrupt then anything before it may be unusable, or at least wrong, unless you can guess what the change was or it doesn't conflict. (Branches are stored as forward diff from their branchpoint, so whole branches from the point of corruption might be problematic.)

2. It can be valid to have a gap in the revision numbering, if a revision has been removed from the RCS file using "rcs -o". A bunch of nulls If you've got a bunch of nulls where a revision should be then this is For example:

   # Setup
   echo 1 > test
   echo "initial commit" | ci -l test
   echo 2 >> test
   echo "2" | ci -l test
   echo 3 >> test
   echo "3" | ci -l test
   
   # RCS file contains revisions 1.1, 1.2, 1.3
   rlog test
   
   # Remove revision 1.2
   rcs -o1.2 test
   
   # RCS file now contains revisions 1.1, 1.3
   rlog test
   

Territus