Is there a tool to recover RCS / CVS, v files?

Question

I am doing a whole bunch of CVS and RCS repository conversions in Subversion. From time to time I come across a damaged v file. I figured out how to fix them manually, but it gets tedious, and my last project has a lot of corrupted files, more than I have to repair manually.

Therefore, I would like to have a tool to analyze and repair RCS files. This may mean that some older versions will be incomplete. For example, I saw cases where version 1.1 was missing, so adding an empty version with a comment indicating that it is missing is a trick.

I tried many times to find such a tool, but did not understand anything. I was about to start writing my own tool, but thought I'd try to ask here first.

I know that I can just get snapshots of the code and import them, and I will resort to this if I need to (just refuse these offers :)

++ thanks

Answer 1

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

There is a tool for porting CVS to SVN and is called cvs2svn . This is a "tool to migrate the CVS repository to Subversion, git or Bazaar." You can refer to this guide for quick advice.

Check this one :

CVS was just an interface for RCS, and * .v files are really RCS files. Just check them out. for example, if you have foo, v just do:

co foo 

and he will check foo from the file, v.

There is also RCS for the SVN converter , and you can try it 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 intended to fix invalid RCS files, but it can be a reasonable starting point if damage occurs only in data sections or if you modify the library to work with any damaged metadata.

Also relevant to your specific question:

• RCS files save the latest version of the chest and unfolds back on the trunk. Therefore, if diff is irreparably damaged for a historical revision, then all that may be unsuitable or at least incorrect if you cannot guess that such a change or it does not conflict. (Branches are stored as a direct diff from their branch point, so whole branches from a corruption point can be problematic.)

• It may be fair to have a space in the revision numbering if the revision was deleted from the RCS file using "rcs -o". A lot of zeros If you have a bunch of zeros where the revision should be, then this: 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