subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Neels J Hofmeyr <ne...@elego.de>
Subject Re: svn commit: r1152410 - in /subversion/trunk/subversion/libsvn_wc: wc-queries.sql wc_db.c
Date Mon, 01 Aug 2011 21:28:36 GMT


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


Mime
View raw message