Kirit Sælensminde wrote:
What I do is to create a directory, _vss_deleted, into which I place these file versions (building the restored directory tree in there). Once it gets to the point of time that the restore is performed then a svn move command puts that directory tree in the correct location.
That's basically the approach we are now taking; you're correct that it's not very elegant but there is really no other way.
One final question if I may - do you run svn commands using the command line client, the API or do you build a dump file?
We create a dumpfile; the layout of it is actually rather straightforward (they have docs in the SVN source tree, but for the most part I just looked at it and figured it out) and it isn't affected by the locale under which the svn.exe command is run. This comes into play when we start importing file names or log comments that have non-ANSI characters in them.
It also allows users to run a tool such as svndumpfilter before actually doing the final import, in case there is any last-minute cleanup they want to perform. The process by which we read the VSS "physical" files also means that it would be very difficult for us to, say, only import a given subtree of the repository, or to exclude a particular directory, or to only import a particular time range. We have to do the whole thing in one shot, so having a dumpfile allows that sort of cleanup to be done prior to the import.
toby _______________________________________________ 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
