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...
Received on 2012-03-26 20:29:04 CEST