According to the normal ID sequence used for physical files, EDADAAAA would imply a physical file allocated earlier than TUADAAAA (as D is before U). Since vss2svn uses this ID reversed as a sort key to disambiguate items with the same timestamp, this would be why the actions get reversed.
I was also astonished by that fact. And no the big question: How can vss generate physical ID prior to the parent phyiscal ID. The only idea that comes to my mind is again the insane ARCHIVE / RESTORE handling.
Ideally I guess it wants some form of sort key that will guarantee that a child item sorts after its parent, but I can't see how to do that at a point where the full parent path is not known.
:-( it seems so..., but we could also introduce a new step to build the parent child hierarchy. This could be possible without the timestamp. We would assign the maximum depth of each physical item in the hierarchy as a new sort string.
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
