Hi Micke,
I wrote that line. It just means that somewhere the trace has been lost
and what was once a MOVE now has several possible places from where it
is being moved. I chose to just leave all the move sources intact, i.e.
SHARE. Perhaps not the wisest thing to do. Some sort of copy might have
been slightly better.
Ok, but this is a little problematic. VSS does not have a concept of shared projects. You can only share files. If you share a project by a "recursive" share, you will create a "shadow" copy of the project structure and share all files. But not the projects itself. So actually there should be never two "identical" sources of a project.

If the source path in a MOVE situation does not exist, we can not simply grab one of the other contexts where this path persisted, since the state of the path in this context must be different, to the state, that we are actually looking for.

I have improved the orphaned handling. Could you please try, whether you still have this situation? Then we can decide about the best way to go. But for now I would say, sharing is only a partial solution and the result can range from, nearly acceptable to completely wrong.

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

Reply via email to