I think the child is *always* a child of the parent. If you want the child to exist independently, and to be added to a specific repository path... then simply use 'svn cp $LOCAL $URL'.
Directory relationships on the client are exactly that: relationship between the parent and the child node. The child goes where the parent goes. I think it would be surprising (in a Bad Way) if a user committed an added tree, only to find that it went "somewhere" because at some point in history the subtree managed to get attached to somewhere *other* than where it appears in the users local arrangement of a checkout. Cheers, -g On Mon, Mar 22, 2010 at 12:07, Julian Foad <julian.f...@wandisco.com> wrote: > 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? > [...] > > >
