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
Index: script/vss2svn.pl
===================================================================
--- script/vss2svn.pl (revision 311)
+++ script/vss2svn.pl (working copy)
@@ -526,13 +526,13 @@
my($sth, $rows, $row);
$sth = $gCfg{dbh}->prepare('SELECT * FROM PhysicalAction '
- . 'WHERE parentdata = 1');
+ . 'WHERE parentdata > 0');
$sth->execute();
# need to pull in all recs at once, since we'll be updating/deleting
data
$rows = $sth->fetchall_arrayref( {} );
- my($childrecs, $child, $id);
+ my($childrecs, $child, $id, $depth);
my @delchild = ();
foreach $row (@$rows) {
@@ -543,6 +543,8 @@
. "'$row->{action_id}'");
}
+ $depth = &GetPathDepth($row);
+
foreach $child (@$childrecs) {
&UpdateParentRec($row, $child);
push(@delchild, $child->{action_id});
@@ -558,6 +560,72 @@
} # End MergeParentData
###############################################################################
+# GetPathDepth
+###############################################################################
+sub GetPathDepth {
+ my($row) = @_;
+
+ # If we've already worked out the depth of this row, return it
immediately
+ if ($row->{parentdata} > 1) {
+ return $row->{parentdata};
+ }
+
+ my($maxParentDepth, $depth, $parents, $parent);
+
+ # Get the row(s) corresponding to the parent(s) of this row, and work
out
+ # the maximum depth
+
+ my $sql = <<"EOSQL";
+SELECT
+ *
+FROM
+ PhysicalAction
+WHERE
+ parentdata > 0
+ AND physname = ?
+ AND actiontype = ?
+EOSQL
+
+ my $sth = $gCfg{dbh}->prepare($sql);
+ $sth->execute( @{ $row }{qw(parentphys actiontype)} );
+
+ $parents = $sth->fetchall_arrayref( {} );
+ $maxParentDepth = 0;
+ foreach $parent (@$parents) {
+ $depth = &GetPathDepth($parent);
+ $maxParentDepth = ($depth > $maxParentDepth) ? $depth :
$maxParentDepth;
+ }
+
+ # Depth of this path becomes one more than the maximum parent depth
+ $depth = $maxParentDepth + 1;
+
+ # Update the row for this record
+ &UpdateDepth($row, $depth);
+
+ return $depth;
+} # End GetPathDepth
+
+###############################################################################
+# UpdateDepth
+###############################################################################
+sub UpdateDepth {
+ my($row, $depth) = @_;
+
+ my $sql = <<"EOSQL";
+UPDATE
+ PhysicalAction
+SET
+ parentdata = ?
+WHERE
+ action_id = ?
+EOSQL
+
+ my $sth = $gCfg{dbh}->prepare($sql);
+ $sth->execute( $depth, $row->{action_id} );
+
+} # End UpdateParentRec
+
+###############################################################################
# GetChildRecs
###############################################################################
sub GetChildRecs {
@@ -739,7 +807,7 @@
my($sth, $row, $action, $handler, $physinfo, $itempaths,
$allitempaths);
my $sql = 'SELECT * FROM PhysicalAction ORDER BY timestamp ASC, '
- . 'itemtype ASC, priority ASC, sortkey ASC, action_id ASC';
+ . 'itemtype ASC, priority ASC, parentdata ASC, sortkey ASC,
action_id ASC';
$sth = $gCfg{dbh}->prepare($sql);
$sth->execute();
This e-mail message and any attachments may contain confidential,
proprietary or non-public information. This information is intended solely
for the designated recipient(s). If an addressing or transmission error
has misdirected this e-mail, please notify the sender immediately and
destroy this e-mail. Any review, dissemination, use or reliance upon this
information by unintended recipients is prohibited. Any opinions expressed
in this e-mail are those of the author personally.
Dirk <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
27-Mar-2007 06:51 PM
Please respond to
Vss2Svn Users <vss2svn-users@lists.pumacode.org>
To
Vss2Svn Users <vss2svn-users@lists.pumacode.org>
cc
Subject
Re: Fw: ssphys error: failed to read necessary amount of data from input
file
Dirk schrieb:
>
>> 86197 TUADAAAA EDADAAAA 1 ADD
>> 1 0 \N
>> 86198 LUADAAAA TUADAAAA 1 ADD
>> /orphaned/_YEDAAAAA/S01/InstallShield/WebGate/Setup
>> Files/Uncompressed Files/Language Independent/ 1
>> 0 \N
Ok, the problem is, that you managed to add a subproject to a project at
exactly the same timestamp as you added the project to its parent
project. vss2svn is confused about this fact, and as a result it first
adds the subproject, then the project itself. The above two actions must
actually be reversed.
Here are the corresponding lines from your physical history without any
confidential information
> 58593 TUADAAAA \N LUADAAAA ADD Language
Independent/ 1 1139237015 xxxx 0 \N 1 AAAADAUT
1 \N \N
> 98983 EDADAAAA \N TUADAAAA ADD OS Independent/ 1
1139237015 xxxx 0 \N 1 AAAADADE 1 \N \N
TUADAAAA is added to LUADAAAA at timestamp 1139237015 .
EDADAAAA is added to TUADAAAA also at timestamp 1139237015 .
Gimme some time to think about a solution.
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
_______________________________________________
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
