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.
What happens if we have an empty <Physical> node, like here:
<Version offset="1140">
<Action ActionId="RollBack">
<SSName offset="0" type="file">ag.h</SSName>
<Physical></Physical>
<Parent>BUEAAAAA</Parent>
</Action>
<Date>924778572</Date>
<UserName>Byrd</UserName>
<VersionNumber>6</VersionNumber>
</Version>
I'm not sure off the top of my head, it depends on what the XML parser
is outputting, but I think that may be a hash ref also, which would
produce the same results. (I guess that's more likely than having two
<Physical> entries!)
_______________________________________________
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
