[PATCH 1 of 1] bdiff.c: implemented block-delimiting to better deal with long "lines"

[Siddharth Agarwal]

On 05/14/2014 04:41 PM, Kastner Masilko, Friedrich wrote:
>> From: Siddharth Agarwal [mailto:sid at less-broken.com]
>>
>> http://mercurial.selenic.com/wiki/ContributingChanges
>>
>> In particular, note the bit about "all lines less than 80 characters"
>> in the patch description.
> Sorry for that, it's been a while since I've last tried to contribute.
>   
>> On the face of it, I think this is a pretty decent idea.
> Thanks. The idea is from this thread, BTW: http://www.selenic.com/pipermail/mercurial/2014-May/047081.html
>   
>> It isn't clear from the patch description whether diffs produced by
>> block-limiting are backwards-compatible. i.e. would a diff produced by
>> this tweaked bdiff be applicable by an older Mercurial? It doesn't seem
>> like you've changed the code that applies diffs, so I presume the
>> answer
>> is yes. Even so, it'll be good to have that explicitly stated in the
>> description.
> Yes, being minimally invasive was the point of this. AFAIK, bdiff generates hunks that consists of starting point, end point, bytes to exchange, and the actual content. The algorithm used to generate those hunks should not influence the algorithm consuming them, otherwise there is implicit knowledge involved. AFAIK, mpatch.c is not doing that, thus old Mercurial versions should have no problem reading revlogs generated by this bdiff.
>
>> Can you add tests to make sure that this works and produces a split
>> output?
> What do you mean with split output? I can make tests that check if the situation shown in the thread linked above is fixed appropriately, i.e. not always storing a snapshot.

Yes, that's what I meant. Sorry about not being clear enough.

>   
>> There's a pure-Python implementation at
>> http://selenic.com/hg/file/1ae3cd6f836c/mercurial/pure/bdiff.py --
>> could
>> you make the same change to this as well?
> I could, but I don't know if it would be as minimally invasive (performance-wise) as the C version is.

If you're using the pure-Python version of Mercurial, you almost 
certainly don't care about performance, so that's OK.