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? > > Any added node has SVN_INVALID_REVNUM. It will not have a revision > until you commit it. It will not have a repository location until you > commit it. > >> But I'm aware that switch can be destructive (e.g. switching forward >> and then back often does not result in the same state). > > Probably more of that bad wc-1 behavior. (Especially with tree-conflicts, switching back and forth non-destructively is probably not something we want to support.) ~Neels