You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Trent Fisher <tr...@oracle.com> on 2012/03/26 18:35:27 UTC
Non unicode characters in log messages
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...
Re: Non unicode characters in log messages
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
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...
Re: Non unicode characters in log messages
Posted by Trent Fisher <tr...@oracle.com>.
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...
Re: Non unicode characters in log messages
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
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...