[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?
thanks,
toby
toby
_______________________________________________
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
