[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: extending the blame callback

From: Stefan Kueng <tortoisesvn_at_gmail.com>
Date: Fri, 11 Jan 2019 17:11:20 +0100

On 10.01.2019 23:46, Branko Čibej wrote:
> On 10.01.2019 19:13, Stefan Kueng wrote:
>>
>>
>> On 10.01.2019 06:58, Branko Čibej wrote:
>>> On 10.01.2019 04:58, Branko Čibej wrote:
>>>> On 07.01.2019 20:57, Stefan Kueng wrote:
>>>>> @@ -758,6 +759,33 @@
>>>>>    * will be true if the reason there is no blame information is
>>>>> that the line
>>>>>    * was modified locally. In all other cases @a local_change will
>>>>> be false.
>>>>>    *
>>>>> + * @note the line is split on LF characters. Clients must be aware
>>>>> of this
>>>>> + * when dealing with different encodings of the file/line.
>>>>> + * Blaming non ASCII/UTF-8 files requires the @a force flag to be
>>>>> set when
>>>>> + * calling the svn_client_blame6 function.
>>>>
>>>> I just noticed that svn_client_blame6 does not, of course, have a
>>>> parameter called 'force'. But it does have a parameter called
>>>> 'ignore_mime_type'.
>>>
>>>
>>> Also the assertion that "lines are split on LF" turns out to be wrong
>>> and misleading. Line endings are translated first, through
>>> svn_subst_stream_translated(), and this happens regardless of the MIME
>>> type. These parts of the new docstrings should be fixed before the next
>>> release.
>>
>> How about this:
>>  * @note the line is split on newline bytes. Clients must be aware of
>> this
>>  * when dealing with different encodings of the file/line.
>>  * Blaming non ASCII/UTF-8 files requires the @a ignore_mime_type flag
>> to be
>>  * set to true when calling the svn_client_blame6 function.
>>
>>
>> mentioning that the split is done on newline *bytes* should be clear
>> enough?
>> Of course, better ideas are always welcome.
>
> I'd just write something about the contents being preprocessed by '@ref
> svn_subst_stream_translated' to convert newlines, as that has its own,
> quite extensive docstring. There's no need to second-guess that or
> duplicate information.
>

how about this:

  * @note the line contents are processed by @ref
svn_subst_stream_translated
  * to convert newlines. The lines are then split on newlines.
  * Clients must be aware of this when dealing with different encodings of
  * the file/line.
  * Blaming non ASCII/UTF-8 files requires the @a ignore_mime_type flag
to be
  * set to true when calling the svn_client_blame6 function.

> Incidentally, this is probably why you don't see any CR bytes. An UTF-16
> sequence of 'CR 00 LF 00' will be translated to 'LF 00 LF 00' and you'll
> get two callbacks out of that instead of one ... I think.

Yes, that's exactly why.

Stefan
Received on 2019-01-11 17:11:34 CET

This is an archived mail posted to the Subversion Dev mailing list.