On 16.01.2019 17:30, Julian Foad wrote:
>> Bert Huijben wrote:
>>> Not sure if that would be as helpful as the old code and/or can be done
>>> with a compatibility wrapper.
> It already is done with the compatibility wrapper.
>
>>> The problem is that the output arguments are
>>> available only, lo
> Bert Huijben wrote:
> > Not sure if that would be as helpful as the old code and/or can be done
> > with a compatibility wrapper.
It already is done with the compatibility wrapper.
> > The problem is that the output arguments are
> > available only, long after the blame reporting is done, [...]
On 15.01.2019 10:49, Bert Huijben wrote:
> Not sure if that would be as helpful as the old code and/or can be done
> with a compatibility wrapper. The problem is that the output arguments are
> available only, long after the blame reporting is done, while with the
> current implementation intermedi
Not sure if that would be as helpful as the old code and/or can be done
with a compatibility wrapper. The problem is that the output arguments are
available only, long after the blame reporting is done, while with the
current implementation intermediate callbacks can be used more efficiently.
Perh
On Mon, Jan 14, 2019 at 4:13 PM Julian Foad wrote:
>
> Julian Foad wrote:
> > The svn_client_blame_receiver4_t parameters "start_revnum" and
> > "end_revnum" do not really belong here because they are not per-line
> > data. They are the "resolved" versions of the input revnums to
> > svn_client_bl
Julian Foad wrote:
> The svn_client_blame_receiver4_t parameters "start_revnum" and
> "end_revnum" do not really belong here because they are not per-line
> data. They are the "resolved" versions of the input revnums to
> svn_client_blame6(). I introduced them in r955895, applying a patch by
>
6 matches
Mail list logo
