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
