Re: recursive/nonrecursive

Kevin Pilch-Bisson <kevin@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
Received on Thu Jul 4 16:24:42 2002