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

Re: [PROPOSAL] WC-NG: merge NODE_DATA, WORKING_NODE and BASE_NODE into a single table (NODES)

From: Greg Stein <gstein_at_gmail.com>
Date: Fri, 3 Sep 2010 11:22:48 -0400

On Fri, Sep 3, 2010 at 04:46, Bert Huijben <bert_at_qqmail.nl> wrote:
>> -----Original Message-----
>> From: Greg Stein [mailto:gstein_at_gmail.com]
>> Sent: vrijdag 3 september 2010 1:14
>> To: Julian Foad
>> Cc: Erik Huelsmann; dev_at_subversion.apache.org
>> Subject: Re: [PROPOSAL] WC-NG: merge NODE_DATA, WORKING_NODE and
>> BASE_NODE into a single table (NODES)
>> On Thu, Sep 2, 2010 at 18:39, Julian Foad <julian.foad_at_wandisco.com>
>> > We need to describe how the layering works for copies, deletes, and
>> > adds.  In particular I'm recalling something about how local adds
>> aren't
>> > recursive, unlike copies, so an additional change within an added dir
>> > doesn't work the same way with regard to op_depth as it would inside
>> a
>> > copied dir.
>> Adds within other adds don't layer. You're simply adding more nodes at
>> the parent's op_depth.
>> Deleting an ancestor of a deleted node also does not create an
>> additional layer. Instead, we establish the new op_depth and relabel
>> all of the deleted children with that new op_depth so that it looks
>> like one big happy delete operation.
>> Copies/moves always introduce a new layer.
> I'm not sure if I follow your reasoning here. (layering vs op_depths)
> I think local additions should always be their own op (and have their own
> op_depth). That would simplify the revert and commit process: They would
> only have to do restructuring changes(add/delete) when there is a new
> op_depth.

A local add is not a restructuring change. It is just adding new nodes
into the tree. You can revert any of those nodes -- you are not
required to revert the root of an add.

You *do* have to go to the root of a copy/move to revert it, however.

There is no way to revert the deletion of a child, so (again) you must
revert a deletion at its op-root.

> So the commit harvester would be as simple as walking the operations (for
> restructuring operations) and checking present nodes for text and prop mods.

And this leads me to think that you're confusing "add" with
"copy/move". Adds never have text/prop mods. The text and props are

IOW, fix your terminology and then I can tell whether we agree or not.


Received on 2010-09-03 17:23:29 CEST

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