On Fri, Sep 3, 2010 at 11:46, Bert Huijben <b...@qqmail.nl> wrote: >> -----Original Message----- >> From: Greg Stein [mailto:gst...@gmail.com] >> Sent: vrijdag 3 september 2010 17:23 >> To: Bert Huijben >> Cc: Julian Foad; Erik Huelsmann; dev@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 <b...@qqmail.nl> wrote: >> >> -----Original Message----- >> >> From: Greg Stein [mailto:gst...@gmail.com] >> >> Sent: vrijdag 3 september 2010 1:14 >> >> To: Julian Foad >> >> Cc: Erik Huelsmann; dev@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.f...@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
