Jon Hardcastle wrote:
Just as a second to what this chap replied with - I
have just finished (well 2months ago) migrating
several repositories with chequered histories at
best.. and all quite large.. I got the best sucess
when i did the following.
...
Create your SVN repos.. and attempt an import. In my
experience it kept falling over on the import back in.
My cut and burn solution to this was to delete delete
the file that caused the problem IN SOURCE SAFE. I
also found that if 1 file in a dir complained it was
likely several would - save yourself some time. if non
of the histories to these files are import purge the
directory containing them..
Repeat until you can migrate, and import without
error.
In the recent conversion I did I found it fairly easy to :
1. svnamin load, observe on which revision it fails
2. 'svndumptool split' [1] 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
(vi!) 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.
I found this much faster than trying to change something in the vss2svn
process, and it guaranteed working results.
-Nathan
[1] http://svn.borg.ch/svndumptool/
_______________________________________________
vss2svn-users mailing list
Project homepage:
http://www.pumacode.org/projects/vss2svn/
Subscribe/Unsubscribe/Admin:
http://lists.pumacode.org/mailman/listinfo/vss2svn-users-lists.pumacode.org
Mailing list web interface (with searchable archives):
http://dir.gmane.org/gmane.comp.version-control.subversion.vss2svn.user
