Hi Jon,
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.
My pin_handler branch was designed to track each revision number for
each item path independently. In order to solve this problem really I
have to weave the delete/recover szenario into this logic.
As I said, bleeding edge ;-)
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
