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