You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Ben Collins-Sussman <su...@collab.net> on 2002/07/03 20:08:16 UTC
recursive/nonrecursive
So I'm working on issue #493, started by pilchie long ago.
Here is a summary of how our client subcommands currently behave:
Normal behavior: Option:
add nonrecursive --recursive
cleanup recursive
commit recursive --nonrecursive
copy recursive
delete recursive
diff recursive --nonrecursive
export recursive
import recursive --nonrecursive
log recursive
merge recursive --nonrecursive
mv recursive
propdel nonrecursive --recursive
propget nonrecursive --recursive
proplist nonrecursive --recursive
propset nonrecursive --recursive
revert nonrecursive --recursive
status recursive --nonrecursive
switch recursive --nonrecursive
update recursive --nonrecursive
And here is a list of TODO items that cmpilato and I think need to be
done, to close this issue:
info nonrecursive
resolve nonrecursive
We should create --recursive options for these subcommands.
checkout recursive --nonrecursive
Yes, you can check out a nonrecursive working copy... but does
this feature acutally work as we want it to?
- 'svn co -n URL' effectively creates a wc of the directory of
depth 1... contains only immediate *file* children, and that's
it...
- Yes, you can commit changes to the file-children.
- Updates don't work, assuming things changed below your wc.
I'm worried about this feature, because it feels half-implemented
to me. I mean, the entries file has *no* idea that its list of
children is incomplete, or that it's in some 'nonrecursive' mode.
Ideally, updates on areas below the top-level dir should be
ignored by the update-editor, or something. Maybe a depth
argument needs to be marshalled all the way over the network to
dir_delta... not sure.
Should we remove this feature? If not, how should we finish it?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: recursive/nonrecursive
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Nuutti Kotivuori <na...@iki.fi> writes:
> I must say that this has bothered me in other places as well. It's the
> same thing that the ls -d switch is made for.
>
> My personal pet peeve is 'svn st -vnu .' It shows me all the entries
> in the current directory - where as I would want it to show only '.' -
> like it does when I say 'svn st -vnu README'.
A useful thing would be to collect scenarios like this, and then look
them over together, to decide if the best solution is a "--depth N"
option, versus an "--i-mean-the-directory-itself" option, versus some
other solution.
I think like it's a bit too early to settle on --depth until we have a
better feel for the actual problems we're trying to solve. It's true
that --depth is elegant in an abstract, conceptual sort of way, but
that doesn't always correspond well to good user interface design.
I've started http://subversion.tigris.org/issues/show_bug.cgi?id=781
about this, and mentioned Nuutti's example in the description. If
anyone else can think of other relevant scenarios, please add them to
the issue.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: recursive/nonrecursive
Posted by Nuutti Kotivuori <na...@iki.fi>.
Kevin Pilch-Bisson wrote:
> Also what about the idea of adding the depth enum, and making commands able to
> operate on:
> depth 0 == entry only
> depth 1 == entry + file children
> depth infinity == entry + all children recursively
>
> The problem is that right now non-recursive is a mix of depth 0 and
> depth 1, and we have no way of performing the other way.
I must say that this has bothered me in other places as well. It's the
same thing that the ls -d switch is made for.
My personal pet peeve is 'svn st -vnu .' It shows me all the entries
in the current directory - where as I would want it to show only '.' -
like it does when I say 'svn st -vnu README'.
-- Naked
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: recursive/nonrecursive
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Just like to add that I share Ben's curiosity here. I'm not dead-set
against nonrecursive working copies, just want to understand the
motivation better -- specific scenarios would help a great deal.
It is a lot of trouble and extra code complexity, so if there's no
broadly compelling motivation, then we probably shouldn't support
this.
I have a vague memory of this discussion being had once before, but I
can't remember if examples were already given. Apologies in advance
if we're asking people to repeat themselves...
-K
Ben Collins-Sussman <su...@collab.net> writes:
> Hm. For some reason, I just don't like the ideas of implementing
> multiple depth levels all over our code. Maybe it's just because it
> means a lot of code perturbance for what feels like little gain to me.
>
> Maybe that's it: I just don't "get" the itch that this is scratching.
> I don't see the need for depth levels, or even the ability to do a
> non-recursive checkout at all. Maybe someone on the list can explain
> why this feature is important? How it's going to make their life
> better? Why would I even *want* a nonrecursive, sticky working copy?
>
> (Even pilchie's propset example above echoes a resounding "so what?"
> in my mind. I can't think of a time I'd ever want to set the same
> property on a dir + file children. I'm more picky than that: I'd
> normally do something like set a property on *.[ch] in the directory,
> allowing shell globbing to do the work.)
>
> I would personally love to just remove the whole nonrecursive wc
> feature.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: recursive/nonrecursive
Posted by Ben Collins-Sussman <su...@collab.net>.
Kevin Pilch-Bisson <ke...@pilch-bisson.net> writes:
> > Should we remove this feature? If not, how should we finish it?
> >
> See http://subversion.tigris.org/issues/show_bug.cgi?id=695
>
> "svn checkout --nonrecursive should be sticky"
Ah yes, I remember this issue now.
>
> Also what about the idea of adding the depth enum, and making commands able to
> operate on:
> depth 0 == entry only
> depth 1 == entry + file children
This seems kind of weird to me. In deltaV, depth 1 means "directory
plus *all* children". Why do we only checkout file children?
> take propset for instance. There is no way to set a prop on a dir + all of
> its file children. It's either the dir only, or fully recursive.
Hm. For some reason, I just don't like the ideas of implementing
multiple depth levels all over our code. Maybe it's just because it
means a lot of code perturbance for what feels like little gain to me.
Maybe that's it: I just don't "get" the itch that this is scratching.
I don't see the need for depth levels, or even the ability to do a
non-recursive checkout at all. Maybe someone on the list can explain
why this feature is important? How it's going to make their life
better? Why would I even *want* a nonrecursive, sticky working copy?
(Even pilchie's propset example above echoes a resounding "so what?"
in my mind. I can't think of a time I'd ever want to set the same
property on a dir + file children. I'm more picky than that: I'd
normally do something like set a property on *.[ch] in the directory,
allowing shell globbing to do the work.)
I would personally love to just remove the whole nonrecursive wc
feature.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: recursive/nonrecursive
Posted by Kevin Pilch-Bisson <ke...@pilch-bisson.net>.
On Wed, Jul 03, 2002 at 03:08:16PM -0500, Ben Collins-Sussman wrote:
>
> So I'm working on issue #493, started by pilchie long ago.
Okay, so I ran out of steam...
>
> checkout recursive --nonrecursive
>
> Yes, you can check out a nonrecursive working copy... but does
> this feature acutally work as we want it to?
>
> - 'svn co -n URL' effectively creates a wc of the directory of
> depth 1... contains only immediate *file* children, and that's
> it...
>
> - Yes, you can commit changes to the file-children.
>
> - Updates don't work, assuming things changed below your wc.
>
> I'm worried about this feature, because it feels half-implemented
> to me. I mean, the entries file has *no* idea that its list of
> children is incomplete, or that it's in some 'nonrecursive' mode.
> Ideally, updates on areas below the top-level dir should be
> ignored by the update-editor, or something. Maybe a depth
> argument needs to be marshalled all the way over the network to
> dir_delta... not sure.
>
> Should we remove this feature? If not, how should we finish it?
>
See http://subversion.tigris.org/issues/show_bug.cgi?id=695
"svn checkout --nonrecursive should be sticky"
Also what about the idea of adding the depth enum, and making commands able to
operate on:
depth 0 == entry only
depth 1 == entry + file children
depth infinity == entry + all children recursively
The problem is that right now non-recursive is a mix of depth 0 and depth 1,
and we have no way of performing the other way.
take propset for instance. There is no way to set a prop on a dir + all of
its file children. It's either the dir only, or fully recursive.
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Kevin Pilch-Bisson http://www.pilch-bisson.net
"Historically speaking, the presences of wheels in Unix
has never precluded their reinvention." - Larry Wall
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~