Dirk wrote:
I hoped that this "HASH(0xc428a34)" kind of errors silently went away.
But it seems, that this is the root of the problem. I have no idea,
where this comes from.
The HASH(...) is what you get when you attempt to use a hash reference
in scalar context, for example:
$a = { foo => 'bar' };
print $a;
It's difficult for me to tell which items are having this problem, but
it looks like $tphysname and/or $parentphys. (In fact the reversed
instance hints at it being $tphysname, since $sortkey is the reverse of
$tphysname).
My guess is that at some point, we are expecting an XML entry to have a
single value but it has multiple values instead. It seems it almost has
to be a <Physical> entry in fact.
Adding the following code around line 428 (right before the
PhysicalAction $cache->add() in GetVssItemVersions) will at least let
you know where the problem is, by using the ref() function, which
returns a true value (specifically, a string with the type of reference,
such as "HASH" or "CODE") if a variable is a reference, or false otherwise:
if(ref($tphysname)) {
print "ERROR: Unexpected hash reference at item $physname, version
$version\n";
}
Then you can inspect the XML output for that physical file at that
version, to see what might be causing the problem.
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
