On 08/01/2011 07:10 PM, Stefan Sperling wrote:
> On Mon, Aug 01, 2011 at 06:56:13PM +0200, Neels J Hofmeyr wrote:
>> On 08/01/2011 04:17 PM, Stefan Sperling wrote:
>>>> And at the same time this update of op_depth==0 rows during revert was not
>>>> necessary before this patch.
>>>
>>> It wasn't necessary because it was cleared by the existing revert code.
>>
>> We had to add to the recursive revert code AFAIR
>
> We added code to recursive revert when we started storing moved-to
> in op_depth=0. Before then moved-to was in op_depth > 0 and cleared
> out as part of existing operation of the revert code.
exactly. What were we talking about again? ;)
>
>> So pretty much my only concern is: do we want to avoid modifying the
>> op_depth==0 nodes?
>
> The benefits of storing moved-to at op_depth 0 should now be quite
> clear. But what's the benefit of not modifying op_depth = 0?
> Note that op_depth=0 is always modified during commit and update.
> It isn't read-only as such.
No, of course not. But it remains untouched all the while that local mods,
including merges, get tossed around in the working copy. There's one
certainty: blow away op_depth>0 and you're back to upstream.
I don't really know what that certainty is good for, and it seems there is
no performance penalty with keeping moved-to in op_depth==0. FWIW the new
certainty goes: blow away all op_depth>0 and set all moved-to to NULL...
While it's only us two arguing and there's no general uproar, I'd say we're
done here. (Y)our patch is good.
~Neels
Received on 2011-08-01 23:29:16 CEST