[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Semantics of --depth: should define WC-depth for omitted-items?

From: Karl Fogel <kfogel_at_red-bean.com>
Date: Fri, 18 Apr 2008 18:01:11 -0400

"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 ...' ?

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.

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.


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 00:01:24 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.