[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [Bug] [Subversion 1.7] svn blame doesn't work for locally modified files

From: Andrey Paramonov <paramon_at_acdlabs.ru>
Date: Fri, 14 Oct 2011 10:47:07 +0400

On 13.10.2011 22:31, Ryan Schmidt wrote:
> On Oct 13, 2011, at 06:51, Andrey Paramonov wrote:
>
>>>> I believe Subversion can automagically translate line ending sequences when transferring data to and from server. I use Windows, so I have CRLF sequences at the ends of the lines in my working copy. The question is: what is the EOL sequence on the server?
>
>
> On Oct 13, 2011, at 07:06, Andrey Paramonov wrote:
>> On 13.10.2011 15:54, Daniel Shahaf wrote:
>>> What properties are set on your file?
>>
>> svn proplist returns nothing.
>
> If the svn:eol-style property is not set on the file, then Subversion does not modify the file in any way as it's stored in the repository. The EOL sequence (and every other byte in the file) is the same on the server as it is on the client.
>
> If, on the other hand, svn:eol-style is set to any valid value, then Subversion stores the file in the repository with LF line endings, and on checkout or export, the client translates the line endings to the style requested in the svn:eol-style property.
>

By looking through the code in libsvn_client/blame.c I see that in
svn_client_blame5 working copy version of the file is unconditionally
normalized to have "\n" EOLs (by call to svn_subst_stream_translated).
However, it seems that svn_ra_get_file_revs2 doesn't do EOL
normalization, at least in my case (absent svn:eol-style).

This explains why it works on *nix regardless of whether svn:eol-style
is set. On *nix, the data has "\n" EOLs in the repository. I believe
you'll be able to reproduce the problem on *nix too if you commit a file
with CRLF line endings. Also, I see that svn blame works correctly for
modified files on my Windows system for files having LF line endings.

I'm not sure what's the best way to resolve the issue. For me, just
removing the call to svn_subst_stream_translated would fix the problem,
I think. But it wouldn't always be TRT in presence of svn:eol-style.

Anyway, please consider reverting svn blame behavior without explicit
@REVISION as the last resort for 1.7.1.

Best wishes,
Andrey Paramonov
Received on 2011-10-14 08:47:56 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.