As far as I can tell blame handles all svn:eol-style values, which can be a
simple 'CR' in which case the normalized form has a plain '\r'. (Only in
case of native and 'LF' the normalized form is a single '\n') Are we sure
this case is properly handled now?
(I read a comment that this is just stripped now)
Bert
On Tue, Jan 8, 2019 at 8:41 PM Stefan Kueng <tortoisesvn_at_gmail.com> wrote:
>
>
> On 08.01.2019 20:30, Michael Pilato wrote:
> >> On 08.01.2019 19:45, steveking_at_apache.org wrote:
> >>> Author: steveking
> >>> Date: Tue Jan 8 18:45:45 2019
> >>> New Revision: 1850781
> >
> > [...]
> >
> >>> Modified: subversion/trunk/subversion/include/svn_client.h
> >>> URL:
> http://svn.apache.org/viewvc/subversion/trunk/subversion/include/svn_client.h?rev=1850781&r1=1850780&r2=1850781&view=diff
> >>>
> ==============================================================================
> >>> --- subversion/trunk/subversion/include/svn_client.h (original)
> >>> +++ subversion/trunk/subversion/include/svn_client.h Tue Jan 8
> 18:45:45 2019
> >>> @@ -736,10 +736,11 @@ typedef svn_error_t *(*svn_client_get_co
> >>> * @{
> >>> */
> >>>
> >>> -/** Callback type used by svn_client_blame5() to notify the caller
> >>> +/** Callback type used by svn_client_blame6() to notify the caller
> >>> * that line @a line_no of the blamed file was last changed in @a
> revision
> >>> * which has the revision properties @a rev_props, and that the
> contents were
> >>> - * @a line.
> >>> + * @a line. The @a line content is delivered as is. It is up to the
> client to
> >>> + * determine the encoding. The line does not contain the cr/lf at the
> end.
> >
> > Minor nit: please use all-caps "CR" and "LF" in this context.
>
> Done.
>
> Stefan
>
Received on 2019-01-09 10:03:55 CET