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 <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?
[...]
Received on 2010-03-22 17:08:14 CET