On Fri, Sep 3, 2010 at 11:46, Bert Huijben <bert_at_qqmail.nl> wrote:
>> -----Original Message-----
>> From: Greg Stein [mailto:gstein_at_gmail.com]
>> Sent: vrijdag 3 september 2010 17:23
>> To: Bert Huijben
>> Cc: Julian Foad; 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 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
>> ALWAYS new.
>
> The commit harvester should be something like:
>
> Phase 1: Walk the tree (limited by depth) to find restructuring operations
> that must be committed. (Handle delete + copy + add (+ in 1.8 move)). Some
> of these operations will apply deeper then the limited depth (See issue
> #3699 and others), but only their operations are handled in these step: not
> local content changes.
>
> (This phase should see each local added directory/file as a separate
> operation, or a svn ci --depth empty DIR would commit all added children.
> Copies are one operation for the entire tree)
>
> Phase 2: Walk the tree (limited by depth) to find which nodes that have a
> pristine version with text or props that differs from the current version.
> (adds are ignored here; already handled in step 1).
>
> This would leave all operations outside the selected depth in the working
> copy for committing later; a much saner operation then the current behavior
> where an add or copy turns a depth limited operation in a recursive commit,
> including all the local modifications deeper in the tree.
How confusing are you trying to make this? You're succeeding wonderfully.
We are talking about *adds* and their op_depth value. What the fuck
does that have to do with commits?
All adds are very simple commit operations. They can all have the same
op_depth value. There are no restrictions on adding more or removing
them. They are free floating nodes within the various restructuring
that copies/moves may have done. You can independently revert any
single add.
Get back to the original question: adds do not require variant
op_depth values. Very simple. Any add under an added parent just uses
that parent's op_depth.
Cheers,
-g
Received on 2010-09-04 06:28:56 CEST