Dukhat wrote:
Odd indeed. As it is r1327 in a 2GB database, it must be fairly early in their development process (before settling into the final form). I can see two alternative solutions to try (though none might work due to secondary problems): * svnadmin load into a sub-folder using --parent-dir. That folder can be erased, no problem.
I actually thought about suggesting that but then wondered whether it would complain even about that. Svnadmin may require that the root of a dumpfile doesn't try to delete itself, regardless of whether it is the actual root of the new repo. I don't know, but it's worth a try.
* Cut away whatever is in and before r1327. If it was a major erase at an early stage, it might not have contained any useful information.
If you go that route, of course use svndumpfilter and don't just hack it off! The third option would be to manually grep for all changes to the root directory (I'm assuming if it was deleted that it was added again) and replace them with no-ops, although doing such surgery on a 2GB file doesn't sound too fun...
_______________________________________________ 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
