On 20 March 2010 06:02, Greg Stein <gstein_at_gmail.com> wrote:
> On Fri, Mar 19, 2010 at 12:37, neels <neeels_at_gmail.com> wrote:
>> On 19 March 2010 07:37, Daniel Näslund <daniel_at_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
Received on 2010-03-22 00:29:49 CET