[EMAIL PROTECTED] wrote on 12/06/2007 12:53:03: > [EMAIL PROTECTED] wrote: > > > > Dirk & All, > > > > I came up with, and coded a solution for this problem. The patch is > > supplied below, if anyone is interested. > > > > To summarise, this is to fix the "svnadmin load" problem where it > > emits the following error: > > > > vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
> > > > > > svnadmin: File not found: transaction '20678-1', path > > 'orphaned/_YEDAAAAA/S01/InstallShield/WebGate/Setup Files/Uncompressed > > Files/Language Independent/OS Independent/setup.bmp' > > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > > > > The main problem stemmed from the following query in the > > BUILDACTIONHIST phase: > > > > my $sql = 'SELECT * FROM PhysicalAction ORDER BY timestamp ASC, ' > > . 'itemtype ASC, priority ASC, sortkey ASC, action_id ASC'; > > > > If 2 or more projects were added at the exact same time, then > > depending on their physical VSS name, they may be returned by this > > query in the wrong order (i.e. ADDing a subproject before its parent > > project has been ADDed). > > > > To fix this, I decided to extend the use of "parentdata" in the > > PhysicalAction table, and instead treat it like a project "depth" > > attribute. During the MERGEPARENTDATA phase, all of the parent records > > are updated with their project path depth as an integer, such that the > > depth increases the further a project/file gets from the root project. > > > > The query is then changed to: > > > > my $sql = 'SELECT * FROM PhysicalAction ORDER BY timestamp ASC, ' > > . 'itemtype ASC, priority ASC, parentdata ASC, sortkey > > ASC, action_id ASC'; > > > > The solution ensures that subprojects will have a parentdata value > > greater than that of their parent project, and therefore be returned > > by this query after their parent project. > > > > This fixed the problem for me. If anyone can think of a better > > solution, go for it. Delving into this problem has made me truly > > realise how badly designed VSS is ! > > > > A disclaimer - PERL is not my forte, so if there is a cleverer way of > > doing it, I'd be happy for people to edit my efforts :-) > > > > Dave > > > > Hi Dave, sorry it took so long to get back to you... as with the > previous patch, I don't have time to test this (and it's not an error I > personally ran into) but it looks logical at first glance so I went > ahead and committed in r313; if it breaks anyone else's conversion > hopefully we'll hear about it! > > However, I notice that you are not doing anything with the return value > of &GetPathDepth() on line 546... it seems maybe that you at first used > a return value then later decided to store it in the database instead? Yes, that's right. You could lose the assignment to $depth.
_______________________________________________ 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
