> -----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,
> >> > adds. In particular I'm recalling something about how local adds
> >> aren't
> >> > recursive, unlike copies, so an additional change within an added
> >> > doesn't work the same way with regard to op_depth as it would
> >> a
> >> > copied dir.
> >> Adds within other adds don't layer. You're simply adding more nodes
> >> 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
> > op_depth). That would simplify the revert and commit process: They
> > 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
> > 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.
Received on 2010-09-03 17:48:15 CEST