No, the data is destroyed by the time it's written out to the file. Consider. There is UTF-8 Arabic in the log. svnmerge.py reads it, and then writes it to a file as mac-roman. It is now destroyed, since Arabic cannot be represented in mac-roman. I will check the config.
On Fri, Oct 9, 2009 at 6:28 PM, Raman Gupta <[email protected]> wrote: > Benson Margulies wrote: > > It's still mac-roman after running the other python you sent. > > Ok. > > > If decoding with sys.stdout.... works, and that is UTF-8, then it cannot > > be true that svn itself is disgorging in the defaultlocale, since the > > Arabic would be corrupted. It really seems that svn log is delivering > > sys.stdout.encoding. > > It looks like your issue is not reading the data output by svn log, > but rather when svn reads the data that svnmerge has created for the > merge commit log message. > > svnmerge appears to think that the encoding of that file needs to be > mac-roman, while svn seems to expect utf-8. > > Can you check in your subversion config whether you have the > log-encoding config value specified? > > > So, the problem happens when this is different from the defaultlocale > > encoding. Thus my desire to be able to control/specify the file encoding. > > I'd rather setup svnmerge.py to automatically select the right > encoding if possible. > > Cheers, > Raman >
_______________________________________________ Svnmerge mailing list [email protected] http://www.orcaware.com/mailman/listinfo/svnmerge
