On Tue, Mar 23, 2010 at 14:13, neels <neeels_at_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
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.
Received on 2010-03-23 22:17:31 CET