Hello Erik,
thanks for looking this up, but it is still very difficult to tell you
the exact course of events.
The SanityChecker tries to follow all svn activities in order to detect
such problem prior to loading the dumpfile into the repository. So the
reason, that it will change an 'change' into an 'add' is really, that
something went wrong in the history of this file. This could be
* renames
* delete / recover activities
* Parent path renames
* or all kind of strange parent paths activities.
Is it possible for you to follow the flow of events for the parent path
back to the root?
When I read your mail I initially thought about the problem, that VSS
can renamed deleted files via a share. So if you undelete a file, you
will get the new name. But I expected that this is correctly tracked in
the SanityChecker.
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
