On Fri, Apr 18, 2008 at 06:01:11PM -0400, Karl Fogel wrote:
> "David Glasser" <glasser_at_davidglasser.net> writes:
> > Well, let's also think one step forward.
> > So we do "svn add --depth=immediates" or something. And either it
> > leaves us with a shallow tree whose depth is immediates with empty
> > children, or infinite with infinite children (and no grandchildren).
> > Whatever.
> > Let's say that the case that the code chose was wrong for our
> > particular use case. I assert that this will be the case for some
> > people no matter what we choose.
> > How do they fix this?
> 'svn add --set-depth ...' ?
I think this is a bad idea. :(
> It does seem to me that giving the added tree depth=infinity, while only
> actually *adding* those parts of it that were reachable via the
> specified operational depth (which may be shallower than infinity),
> leaves the user in the best position. The tree will behave in a
> perfectly predictable way afterwards, the user doesn't have to remember
> what depth it was added at, and if someone else later commits things
> deeper under that tree, it's more likely than not that the original user
> would want to know about that at update time.
> However, adding the tree at the specified depth is probably what the
> user would *expect*. Sometimes, what is most intuitive is not the same
> as what is most useful. So I could (sigh) go either way on this one.
Agree. There is no obvious best choice to satisfy all here. Both choice are
reasonable from its standpoint and inevitably have some shortcoming. We can
choose to accept current behavior and document the divergence, or to maintain
the consistency by modifying the current behavior.
It's the decision itselfthat most important. Both choice are acceptable to me.
Though I personally prefer the consistency a little, slightly...
> The proposed "middle ground" behavior makes me tremble, when I think of
> describing it to users who, say, haven't personally implemented depth in
> the Subversion code themselves.
The "middle ground" seems not actually exists. See my discussion with C.
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-04-19 08:22:39 CEST