Ben Collins-Sussman wrote:
>Branko Čibej <brane@xbc.nu> writes:
>
>
>
>>Ben Collins-Sussman wrote:
>>[lots of things]
>>
>>Interesting plan. I wonder, though, if it's better than doing a
>>breadth-first checkout instead of a depth-first one, like we're doing now.
>>
>>
>
>That's equivalent to tossing libsvn_wc/update_editor.c. That is, it
>means coming up with a completely new breadth-first system for
>checkouts, one which doesn't involve using an editor at all. I don't
>think any of us were comfortable with that idea. At least for us,
>that would be a last-ditch strategy of desperation. :-)
>
O.K.
>>What happens when you do "svn co -N repos; svn up"?
>>
>>
>
>What is -N? What does that mean, depth 0? Depth 1?
>
Let's not be so pedantic, eh? Of course it means --depth=1 in this case;
I don't care about the name of the switch, its the semantics that are
important here. So, let me rephrase the question:
What happens if you do a non-recursive checkout of a directory, one that
only pulls its immediate children, and then run "svn up" in that working
copy? Does the update ignore the non-recursiveness of the checkout? Do
directory children even show up in a non-recursive checkout?
Heh, and note that "svn co --depth=0" doesn't make sense, so "svn co -N"
is quite unambiguous.
>I've made my opinion known before: I think we should banish the -N
>switch, because at the moment it's a) ambiguous, b) half-implemented
>for many commands, and c) inconsistent across commands.
>
No, we should just define what -N means for each specific command. It's
a useful shortcut, just like -R. So, a) and c) are only a problem until
the behviour is documented -- assuming, of course, that the rules for
chosing --depth=0 or --depth=1 behaviour are consistent and logical. b)
isn't going to go away just because the name of the switch changes.
>I'm very much looking forward to cmpilato's push to create a --depth
>argument as a replacement.
>
>
Sure, so am I.
--
Brane Čibej <brane_at_xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat May 10 11:08:13 2003