My analysis of the python code is different. It is assuming that the log contains UTF-8, and then it is insisting on converting it to 'the current locale' before letting you edit it. If the current locale isn't UTF-8, and it probably isn't, you lose.
Converting is not safe, but it's convenient for some people some of the time. So I propose an option to turn it off and write UTF-8 (perhaps with a BOM). On Wed, Oct 7, 2009 at 12:12 PM, Raman Gupta <[email protected]>wrote: > Dustin J. Mitchell wrote: > > On Tue, Oct 6, 2009 at 4:55 PM, Raman Gupta <[email protected]> > wrote: > >> Romulo Ceccon was the primary author, with some input from me. Check > >> this mailing list thread: > >> > >> > http://thread.gmane.org/gmane.comp.version-control.subversion.svnmerge.devel/872 > >> > >> The revisions to review are 29666 with a few others after that one to > >> fix some regressions (searching for 29666 should find most or all of > >> them). > > > > So .. any idea how to fix the current quandry? > > As far as I recall (and with a brief review of the thread I referenced > above to refresh my memory) svnmerge is, when reading the log messages > printed by svn, trying to use the same encoding as that used by svn to > output them. It does this by reading in the current default locale, > which is what I believe svn outputs, with the caveat below. > > As per some comments in svnmerge.py there is one situation which isn't > currently handled: that is when log-encoding is specified in the svn > configuration. In that case, svnmerge.py's assumption of the log > encoding used by svn will probably be wrong. Is this the case for you > Benson? > > If so, a patch is needed to svnmerge.py to handle this by reading the > svn configuration and checking for the log-encoding setting. > > If not, then we need to investigate, in Benson's specific case, what > logic svn is using to determine the encoding of the log message output > -- then patch svnmerge.py to replicate that logic. Or alternatively > tell svnmerge.py to force svn to always output log messages in UTF-8 > and set svnmerge.py to read in the same. > > If the first approach is taken, Someone would likely need to check the > svn code or ask on the svn dev list. Daniel Shahaf on #svn was helpful > the last time around. > > A new test case would also be helpful. > > Cheers, > Raman >
_______________________________________________ Svnmerge mailing list [email protected] http://www.orcaware.com/mailman/listinfo/svnmerge
