Yeah, a similar issue was fixed for the post-commit hook error output. FWIW it works for me with a trunk client/server ---
% $svn log http://localhost:8081/t/r1 ------------------------------------------------------------------------ r1 | daniel | 2012-03-26 20:26:56 +0200 (Mon, 26 Mar 2012) | 2 lines Initial import.á § セ ------------------------------------------------------------------------ I don't have a 1.7.x build handy, sorry. Daniel Trent Fisher wrote on Mon, Mar 26, 2012 at 13:58:35 -0400: > The server has Subversion 1.6.16 and Apache 2.2.15. It happens on > most clients I have tried including Tortoise SVN 1.6.7 and I think > the person who discovered it was running 1.7, and from the command > line I tried versions 1.6.6 and 1.6.16. > > Perhaps this is something fixed in 1.7? > > On 03/26/2012 12:59 PM, Daniel Shahaf wrote: > >What version of svn on the client and on the server? (Go to http://../ > >in a browser and check hte footer) > > > >Trent Fisher wrote on Mon, Mar 26, 2012 at 12:35:27 -0400: > >>I think I found a bug relating to handling of non-unicode characters > >>in log messages. When I do an "svn log" via the file:// url it > >>works fine, but when I do it via http:// the history is truncated > >>and ends with this message: > >> > >>svn: REPORT of > >>'/svn/tugbu/!svn/bc/236146/QA/CCB/main%20V2.4.X/Documentation/Test%20Plans/Rate%20Engine/Version%202': > >>200 OK (https://adc4110279.us.oracle.com) > >> > >>I figured out that the next revision which would have been displayed > >>contained non-unicode characters. From what I have gathered via > >>some Google searches, Subversion shouldn't accept such things, > >>though old versions did, and svndump load will let such things in > >>(which means I have a bug in my import script). > >> > >>One side effect of this "error" is that TortoiseSVN thinks the sever > >>has gone down and offers to go into offline mode. > >> > >>If I got rid of the non-unicode characters in the log message, that > >>error went away. FYI the following command seemed to do the trick > >>for getting rid of the bad characters, since propget displayed the > >>bad characters with backslash escaped octal sequences (i.e. ascii). > >> > >>svn propget --revprop -r236146 svn:log file:///scm/svn/repos/tugbu | > >>svn propset -F - --revprop -r236146 file:///scm/svn/repos/tugbu > >> > >>So, it seems to me that this is a bug. Subversion should degrade in > >>a more graceful way when this happens, no? I looked a bit through > >>the Issues list, but didn't see anything like this. > >> > >>++thanks, > >>trent...
