Re: switching added files -- Re: What revision should an added not yet commited node have?

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
  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
Received on 2010-03-23 22:17:31 CET