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.foad_at_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 <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:20:39 CET