[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: Konstantin Kolinko <knst.kolinko_at_gmail.com>
Date: Fri, 14 Oct 2011 11:43:14 +0400

2011/10/14 Andrey Paramonov <paramon_at_acdlabs.ru>:
> 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).

Confirming that the issue reproduces for me on Windows using a file
that does not have svn:eol-style property.

The svn blame filename_at_BASE, as mentioned earlier, works correctly,
blaming unmodified base version of the file.

If a file has svn:eol-style=native the issue does not reproduce
and blame works correctly.

>
> 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 regards,
Konstantin Kolinko
Received on 2011-10-14 09:43:49 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.