[EMAIL PROTECTED] wrote:
[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.
OK, just wanted to make sure before I went and deleted it. Thanks again
for the patch...
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
