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
