2011/10/14 Andrey Paramonov <para...@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@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
