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

Re: svn commit: r1152410 - in /subversion/trunk/subversion/libsvn_wc: wc-queries.sql wc_db.c

From: Neels J Hofmeyr <neels_at_elego.de>
Date: Mon, 01 Aug 2011 23:28:36 +0200

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.


Received on 2011-08-01 23:29:16 CEST

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.