Fixing The Dumpfile

How to manually edit your dumpfile to fix errors on svnadmin load

After your conversion runs and you svnadmin load your dumpfile you may easily run into an error reported by svnadmin, indicating the dumpfile has a problem. Rather than trying to remove the offending file from the original VSS repository, or make a change in the vss2svn code, it is often much faster to fix the dumpfile itself. This method also guarantees working results.

1. svnamin load your dumpfile, observe on which revision it fails
2. Using svndumptool (see version note below), svndumptool.py split the failing revision out of the main dumpfile such that you get A.dump (revisions before bad rev), B.dump (the bad revision) and C.dump (revisions after bad rev).
3. Open B.dump in your favourite editor that won't mangle binary data (vim works) and fix it. (Does a parent directory need to be created? Is a rename wrong? Forcibly "un-orphan" a file by reconnecting its path to its true parent, etc.) The format is pretty easy to work with if you're careful -- just copy an entry similar to what you want and tweak.
4. svnadmin load A.dump, B.dump, C.dump
5. Goto 1, for any problem in C.dump.

Notes:

• Unless you ran your vss2svn conversion with the --md5 flag you will need to get svndumptool from trunk @ revision 207 or greater (or use version 0.5 or greater after it is released). Otherwise it will choke when it doesn't find Text-content-md5 headers.
• Splitting the dumpfile isn't strictly necessary depending on how big it is. If you've got a very fast machine with lots of memory you may find loading a few hundred MB dumpfile into your editor is faster. (Or, putting it on a ramdrive and then loading in your editor.) However, for dumpfiles that are several GB, especially over the 2³² byte limit, you'll need to split the dumpfile.

Fixing Specific Errors

Parent Directory Not Found

svnadmin reports:

<<< Started new transaction, based on original revision 550
     * adding path : Project/Foo/Baz.h ...svnadmin: File not found: transaction '549-1', path  Project/Foo/Baz.h'

Problem: There's no Add action to create "Project/Foo". This may have been caused if you used svndumpfilter to trim obsolete directories from the dumpfile. For example, svndumpfilter include "Project/Foo" probably will remove the creation of the Project directory.

Fix:

1. svndumptool split 1-549,
2. svndumptool split 550 by itself.
3. manually add creation of Project/Foo dir to 550 dumpfile. E.g.

   Node-path: Project
   Node-kind: dir
   Node-action: add
   
   Node-path: Project/Foo
   Node-kind: dir
   Node-action: add
   
   

4. svnadmin load 1-549,
5. svnadmin load 550

Orphaned Files

Problem: Files are put under /orphaned when you know where they really should belong.

Fix:

1. (optional) Load the dumpfile to a test repository so you can use use e.g. TortoiseSVN's powerful log searching to find the revisions the orphans are made in.
2. Split the problem revision and simply change the Node-paths from under /orphaned to the correct path. Be sure to create directories that don't already exist.

You may also want to check this tool: http://svn.pumacode.org/repos/vss2svn/trunk/contrib/filterorphan

Missing Files

Problem: When comparing your final svn repo with vss you see svn is missing files.

Fix: First, make sure the file wasn't improperly deleted, or copied to a wrong place, in the svn history. If the file (or whole tree) simply never was added you can easily add it in.

1. Check the VSS history to find when the files were added
2. Check the SVN history to find an appropriate revision that corresponds to the time and/or "changeset" of the files. Say revision 5.
3. svnadmin create an empty test repo
4. Check out the test repo and add all the missing files into the right tree structure, then commit
5. svnadmin dump -r 1 --incremental test > addfiles.dump
6. Remove the revision headers from addfiles.dump, leaving just the Node actions
7. Split revision 5 identified in from step 2.
8. cat addfiles.dump >> rev5.dump
9. Load the new rev5.dump.

Dumpfile Is Corrupt

svndumptool.py or svnadmin report something like:

expected empty line, found '(!file.IsEndTag(tag'ame))

Problem: The dumpfile may be corrupt. Example I found: While vss2svn BUILDACTIONHIST listed it had gone over all revisions, internally revision 22392 was corrupted. The next revision listed in the dumpfile was 25604. All told, the dump was missing revisions: 22393 - 25603, 26475 and 26970 (3213 revisions)

Fix: Don't use vss2svn win32 precompiled executables. Instead build /trunk on Linux. Several times faster and works correctly.