Hello
thanks for the nice words.
This XML Parser Error seems to be the last major issue ;-) The problem
is, that there is really garbage in your data, and also that analyse
does not remove it. In the first hand I fixed the XML output within
ssphys, but this led to the problem, that I also filtered non latin
characters. So we changed to perform the filtering in vss2svn. But for
some reason, this still fails since we always encounter new problematic
"binary junk". And finally the XML parser simply exits the process.
It is possible that you have better success with an older release,
simply due to the fact, that I filtered junk data in ssphys.
The very interesting thing is, that it is complaining about a 0x12
character, which is already filtered:
$gSysOut =~ s/[\x00-\x09\x11\x12\x14-\x1F\x81\x8D\x8F\x90\x9D]/_/g;
# just to be sure
Can you send me your problematic file in a private mail. I will input it
in my processing chain and see, why it is not correctly handled.
Best regards
Dirk
Luis A. Montes schrieb:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
Great project. I've been trying to port a medium size source safe
database for a month now, on and off, and tried couple of other
programs, but I'm still not done yet. One thing that I though would be
very useful in in your script is label support. So I tried the latest
nightly build. But it kept failing with the same:
WARNING: control character 0x12 in text input at character 14
not well-formed (invalid token) at line 23, column 24, byte 823 at
/PerlApp/XML/Parser.pm line 187
that other people have reported previously. I ran with the --debug and
- --verbose flags and I did find that one entry did have a suspicious
entry at the end:
<CheckOut offset="416">
<Comment>?</Comment>
<ParentSpec></ParentSpec>
<Computer></Computer>
<Folder>ÓD`ôD`h` à</Folder>
<User></User>
</CheckOut>
I had ran the VSS analyze beforehand and corrected the (apparently)
benign errors it found, but figuring it was probably in the data I
proceeded to remove the file, re-run analyze (that now found potentially
serious errors) and run the conversion again with similar results. So I
decided that I should try the latest stable release (0.11.a1) and that
is still running, beyond the task (getphyshist) where the other failed.
Is the new approach more fragile, or am I expecting too much from a
nightly build?
Anyway, I need to get this done, with labels, but I'm thinking that
perhaps I can run the 0.11.a1 build and get the svn server in place, and
then when the label support is more stable, I can dump the subversion
database, cut the old stuff and splice the new vss2svn dump file with
the dump of the stuff added in subversion. That will also buy me more
time to help test the label support. I don't see why it wouldn't work
... anyone?
Thanks
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGrWULJ4+d0CQL2bIRAnLyAKCS38/qNhnht6NKm0lWU8QDhsH8CwCfYlU5
+ZwvGRhSgYWZ1Qf3cSaCUv8=
=dv3t
-----END PGP SIGNATURE-----
_______________________________________________
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
