But you can perform intensive testing after it is finished. I will
have some time this night. If I'm not to tired I will try to make
some progress on these issues.
I just have reverted the delete/recover handling to the algorithm
used in the beta-2 version. This is that the deleted items are
tracked seperately. If you want to help, you can test the latest
revision. I have not done intensive testing with my archive. So be
aware, it could brake in other scenarios.
I don't have much time currently, so I didn't tested this modification
on my archive. I have done this now, and it seems, that the change was
to short sighted. When you have shared an item between two projects
and you delete it from both projects only the last revision number is
remembered. When you recover the first delete you will run into
problems again, since the revision number is the wrong one.
I have checked in a quick and dirty fix. I haven't tested it on my full
archive, but my test scenario works. You need to rerun the conversion
process from the whole beginning (except probably --resume --task INIT)
since I changed the database layout.
I will now merge the latest changes from the trunk to allow the
selection of the XML parser to speed up the conversion process. Also you
should really make sure, that you are working locally, the best on two
harddrives. One where the vss archive is stored and the second, where
the temporary files are stored.
Dirk
_______________________________________________
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
