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

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.

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