On 22 March 2010 17:20, Greg Stein <gstein_at_gmail.com> wrote:
> I think the child is *always* a child of the parent.
Greg, you definitely know that this works today:
[[[
$ svn add bar/y
A bar/y
$ svn ci -mm
Adding bar/y
$ svn switch --depth=empty '^/foo' bar
At revision 1.
$ svn status
S bar <--- file:///repos/foo
S bar/y <--- file:///repos/bar/y
]]]
There is a separation between bar and y, and I would argue that y is
not the true child of the switched bar.
So why not allow this as well:
[[[
$ svn add bar/y
A bar/y
# NOT: $ svn ci -mm
# NOT: Adding bar/y
$ svn switch --depth=empty '^/foo' bar
At revision 1.
$ svn status
S bar <--- file:///repos/foo
A S bar/y <--- file:///repos/bar/y
]]]
If a user explicitly asks for an empty depth, we should either allow
disconnecting an added child from its parent during switch, OR we
should loudly fail, since we are not conforming to the requested
depth. Greg, are you saying we should bail on this case? Looking at it
this way, I prefer the analogy to a modified node, where the mods do
stay at the "unswitched" URL even if the parent is switched away, and
I'd allow switching the parent of an added node away. But we would
also have to allow explicitly switching an uncommitted add to another
path (as with Julian's Switch-Duality Theorem). Looking at it that way
it's not important enough to bother supporting it ... or is it,
Julian?
~Neels
>
> 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-23 19:14:19 CET