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)
<at> <at> -526,13 +526,13 <at> <at>
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 <at> delchild = ();
foreach $row ( <at> $rows)
{
<at> <at> -543,6 +543,8 <at> <at>
. "'$row->{action_id}'");
}
+ $depth
= &GetPathDepth($row);
+
foreach
$child ( <at> $childrecs) {
&UpdateParentRec($row, $child);
push( <at> delchild, $child->{action_id});
<at> <at> -558,6 +560,72 <at> <at>
} # End MergeParentData
###############################################################################
+# GetPathDepth
+###############################################################################
+sub GetPathDepth {
+ my($row) = <at> _;
+
+ # 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( <at> {
$row }{qw(parentphys actiontype)} );
+
+ $parents = $sth->fetchall_arrayref(
{} );
+ $maxParentDepth = 0;
+ foreach $parent ( <at> $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) = <at> _;
+
+ 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 {
<at> <at> -739,7 +807,7 <at> <at>
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 <vss2svn <at> nogga.de>
Sent by: vss2svn-users-bounces <at> lists.pumacode.org
27-Mar-2007 06:51 PM
Please respond to
Vss2Svn Users <vss2svn-users <at> lists.pumacode.org> |
|
|
To
|
Vss2Svn Users <vss2svn-users <at> 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:
RSS Feed