This dialogue touches on an important issue: the relationship of a child node to its parent node in the WC and its path in the repository. But the dialogue included statements about UI requirements and stetements about libsvn_wc implementation without saying which were which.
I am trying to present here my views that: * both "this node is a child of its WC parent directory" and "this node belongs at an explicitly specified repository path" are useful logical concepts at the UI level; * the WC already needs to support both of these concepts; * these two concepts apply to added and deleted nodes just as to modified or untouched nodes, even if an absolute location is rarely useful in practice with an added or deleted node; * designing to support these combinations is a matter of keeping the kind of change orthogonal to whether the node has a specified repository path (aka "is switched"), and orthogonality helps to manage the complexity of a design. UI REQUIREMENT Let's get the UI requirement clear first, before we look at the WC library. The first question is: Do we want an added child to stay attached to its WC parent while that parent is moved, copied, switched, etc., or do we want it instead to be attached to its initial repository path? Leaving aside "--depth=empty" for a moment, I think the answer is clear: in normal usage, most users would want and expect the child node to stay with its WC parent directory. And the same for a modified or deleted child, not just an added child. A child is considered to be a child of its local parent. Now, could a user reasonably want a locally added node to remain scheduled for add at its original repository path while its WC parent directory is moved, copied, switched? There are surely a few times when a user could want that, but it's not exactly a priority feature, so is it wise for Subversion to support that? Before we look at an added child node, let's look at what we support with an existing child node. If we move or switch a parent directory with --depth=empty, that should result in each of its children appearing to be switched (relative to the WC parent) back to its original path. Crazy or reasonable? Note in the first place that we already supported this end result without needing --depth=empty, because the user could always switch the parent recursivley and then switch each immediate child back again. It is not extraordinary to expect a single switch with "--depth=empty" to achieve the same result. We note also the close similarity of a "switched" child to an "external" child. (I'll discuss this similarity in another thread.) In the case of an "external" definition, the definition itself specifies whether the target path is relative to its local parent or not. If it works with an existing node, then for consistency it should work with added and deleted nodes too. But isn't it silly to allow a child that is sheduled for addition to be switched to another repository path, and indeed to allow it to have any fixed notion of what repository parent path it will be added to? Not at all. It might be more complexity than most client programs wish to provide most of the time, and it might be a case that we don't think is important enough to provide low-level support for, but it is inherently a logical and perfectly sane behaviour. And similarly for a node scheduled for deletion. Back to the original question: in the UI, is a child considered to be a child of its WC parent dir, or a child of its (initial) repository path? Answer: the former, normally; but the latter when explicitly requested. So do we need to be able to support both in the WC? Yes, I believe so, and I would expect that as the "switch" mechanism handles the "specified repository path" concept, the normal mechanism should exclusively and comprehensively handle the "child of its WC parent dir" concept. Thoughts? - Julian On Mon, 2010-03-22, neels wrote: > On 20 March 2010 06:02, Greg Stein <gst...@gmail.com> wrote: > > On Fri, Mar 19, 2010 at 12:37, neels <nee...@gmail.com> wrote: > >> On 19 March 2010 07:37, Daniel Näslund <dan...@longitudo.com> wrote: > >>> I have some quirks with switching locally added files but that's for > >>> another post. > >> > >> I once tested that switching the parent away depth-empty above an > >> added node works, and that the added node correctly keeps its previous > >> URL. > > > > There is nothing "correct" about that. It is an artifact of buggy wc-1 > > behavior. When you add a node, it will be committed under its > > *current* parent. Not whatever it happened to be six weeks ago when > > you did the "svn add". The URL reported was wrong/bad/etc. > > I once started off with the assumption that an added node is closely > tied to its immediate parent, but found things to go otherwise. Some > discussions (mis?)led me to believe that an added node should actually > be handled as independently as possible from the node under which it > was added... i.e. rather once-off note all info from the parent during > 'svn add', after which the added subtree is 'autonomous' and does not > need to query the op-root's parent anymore. > > If you switch a folder --depth=empy, it can make sense to the human > mind to not switch added child nodes along. It's explicitly > --depth=empty after all. > > Other than that, I actually favour letting added subtrees stick to > their immediate parent until commit. For tree-conflicts info, this > enables obtaining a > revision-at-which-this-added-node-is-known-to-not-have-existed without > introducing an explicit field in the ng-WORKING tree node. > > I remember Bert arguing against such behaviour, talking of > switched-away parents and <no recall>. I may remember wrongly. But > there *are* problems with --depth: > > I want to be able to assume that if the parent of an added node is at > revision X, then the added node's path did not exist in revision X. > However, if a folder has an added subtree, and that folder is updated > --depth=empty, it advances to X+1, technically not bothering with > (added) children. ... is it / will it be verified during that update > that the list of children of that folder does not collide with locally > added nodes? [...]
