On Tue, Mar 23, 2010 at 14:13, neels <[email protected]> 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
