You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Greg Stein <gs...@gmail.com> on 2010/03/20 05:02:03 UTC
Re: switching added files -- Re: What revision should an added not
yet commited node have?
On Fri, Mar 19, 2010 at 12:37, neels <ne...@gmail.com> wrote:
> On 19 March 2010 07:37, Daniel Näslund <da...@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.
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.
Cheers,
-g
Re: switching added files -- Re: What revision should an added not
yet commited node have?
Posted by neels <ne...@gmail.com>.
> "svn switch" talks about switching the repository location for nodes. The
> added (or copied/moved) nodes do not (yet) have a repository location, so
> they cannot be switched. They just follow the parent.
It's not like that is set in stone. An added node could have a
*projected* repos location, derived from the parent at the time of the
add. The question is which makes more sense in terms of the API.
If users issue a depth that, by the literal meaning of the word
*empty*, suggests that it excludes all children, added or not, they
may be very confused to see adds of several levels below following the
switch. It would make most sense to bail instead: "Why are you trying
to exclude added children that are semantically attached to the path
you are switching? Don't do that, it's a misconception."
(curious what Julian has to say about why both should be supported)
~Neels
Re: switching added files -- Re: What revision should an added not
yet commited node have?
Posted by Greg Stein <gs...@gmail.com>.
On Tue, Mar 23, 2010 at 14:13, neels <ne...@gmail.com> wrote:
>...
> [[[
> $ 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
> ]]]
I would suggest the above becomes:
$ svn status
S bar
A bar/y
The add will still occur under "bar" which now refers to file:///repos/foo,
so you'll end up with file:///repos/foo/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
I'm saying (uncommitted, added) nodes are *added* into the directory their
parent refers to. In the above example, you've switched the nodes which have
a correspondence in the repository, and the added nodes simply follow.
> 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,
"svn switch" talks about switching the repository location for nodes. The
added (or copied/moved) nodes do not (yet) have a repository location, so
they cannot be switched. They just follow the parent.
Cheers,
-g
RE: switching added files -- Re: What revision should an added not yet commited node have?
Posted by Bert Huijben <be...@qqmail.nl>.
> -----Original Message-----
> From: neels [mailto:neeels@gmail.com]
> Sent: dinsdag 23 maart 2010 19:13
> To: Greg Stein
> Cc: Julian Foad; dev@subversion.apache.org
> Subject: Re: switching added files -- Re: What revision should an added
> not yet commited node have?
>
> On 22 March 2010 17:20, Greg Stein <gs...@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.
Note that while this might be/look supported... it is also a typical example
which triggers issue #3569.
You switch the directory to a new revision, but don't update its list of
children to match that revision. So you will never receive the children of
the node, even if you perform svn update --set-depth infinity.
(There is no way to fix this situation except switching this node back to
its original location@rev with depth empty and then performing the switch
recursively)
Bert
Re: switching added files -- Re: What revision should an added not
yet commited node have?
Posted by neels <ne...@gmail.com>.
On 22 March 2010 17:20, Greg Stein <gs...@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 <ju...@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 <gs...@gmail.com> wrote:
>>> > On Fri, Mar 19, 2010 at 12:37, neels <ne...@gmail.com> wrote:
>>> >> On 19 March 2010 07:37, Daniel Näslund <da...@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?
>> [...]
>>
>>
>>
>
Re: switching added files -- Re: What revision should an added not
yet commited node have?
Posted by Greg Stein <gs...@gmail.com>.
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 <ju...@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 <gs...@gmail.com> wrote:
>> > On Fri, Mar 19, 2010 at 12:37, neels <ne...@gmail.com> wrote:
>> >> On 19 March 2010 07:37, Daniel Näslund <da...@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?
> [...]
>
>
>
Re: switching added files -- Re: What revision should an added not
yet commited node have?
Posted by Julian Foad <ju...@wandisco.com>.
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 <gs...@gmail.com> wrote:
> > On Fri, Mar 19, 2010 at 12:37, neels <ne...@gmail.com> wrote:
> >> On 19 March 2010 07:37, Daniel Näslund <da...@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?
[...]
Re: switching added files -- Re: What revision should an added not
yet commited node have?
Posted by neels <ne...@gmail.com>.
On 20 March 2010 06:02, Greg Stein <gs...@gmail.com> wrote:
> On Fri, Mar 19, 2010 at 12:37, neels <ne...@gmail.com> wrote:
>> On 19 March 2010 07:37, Daniel Näslund <da...@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