> -----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.
Bert
Received on 2010-09-03 17:48:15 CEST