Remember that the reason we introduced the converter was because the
original code was just smashing all non-ASCII out of the output. No
"conversion" was happening, but a bogus encoding was declared in the
XML header. If we try to preserve the smashed characters, Perl's XML
parser gets upset because of their invalid XML encoding.
That is right, since we actually didn't convert anything in ssphys. We
just removed the "discouraged" characters. The bogous charset definition
is also not that bogous, since it is the charset, that I'm using ;-)
hardcoded into the converter.
Are the hotfixes you mention in the repository?
No, the hotfix is to overwrite the encoding in the Dumpfile.pm to the
"source" encoding of your current locale. So we use the "CP1252" only as
a transport medium, regardless of the content, even if it doesn't make
sence in this codepage, and then force the input to a different codepage
in vss2svn. If we use the utf8 branch, this hotfix is not possible any
more, since the input is already converted.
I can look them over and see if there's a way to keep everybody happy.
I know this is an annoying issue. Does Windows have an included UTF-8
encoder?
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
