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.
Received on 2012-03-26 19:59:15 CEST