[ switching list, please drop users@ from further replies ]
Konstantin Kolinko wrote on Fri, Oct 14, 2011 at 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.
>
>
@Both, thanks for the analysis. Could someone file a bug report and/or
send a patch, too? If you have a build environment, does the patch
below fix the problem?
[[[
Index: subversion/libsvn_client/blame.c
===================================================================
--- subversion/libsvn_client/blame.c (revision 1182771)
+++ subversion/libsvn_client/blame.c (working copy)
@@ -473,6 +473,9 @@
svn_io_file_del_on_pool_cleanup,
filepool, filepool));
+ cur_stream = svn_subst_stream_translated(cur_stream, "\n", TRUE, NULL,
+ FALSE, filepool);
+
/* Get window handler for applying delta. */
svn_txdelta_apply(last_stream, cur_stream, NULL, NULL,
frb->currpool,
]]]
> >
> > 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 12:50:28 CEST