Re: Issue 493

Kevin Pilch-Bisson <kevin@pilch-bisson.net> wrote nearly this:
> add non-recursive switchable (becomes import??)
> checkout recursive switchable

I'm not sure how a non-recursive checkout would result in a useable
working copy, but there may be a way. Maybe we should make "checkout
-n" a low priority, though?...

> commit recursive switchable
> delete recursive non-switchable (you can't remove a =
> dir, but not it's children)
> import recursive switchable (?)

Well, do we really need a non-recursive import? Nah... :-)

> proplist non-recursive switchable (change output to display
> name of node prop belongs to in
> recursive case)

Yeah, good point.

> propget non-recursive switchable (as above)
> propset non-recursive switchable (as above)
> propdel non-recursive switchable (as above)

+1

> *status recursive switchable
> *diff recursive switchable
> update recursive switchable
> cleanup recursive non-switchable (doesn't make sense =
> to
> clean just part of a wc).

Agree.

> revert currently non-recursive, switchable
> desired behaviour?

Non-recursive default seems like a good idea, but switchable, yeah.

> The other issue is what behaviour does --non-recursive have. My idea was t=
> hat
> if the target is '.' then is works on all files/dirs in the present dir. If
> the target is a non-'.' dir, then it will work exclusively on the dir.

Something like that. A simpler way to say it might be:

   When a command is run non-recursively, each dir argument received
   is treated like this: the command is run on all the files in the
   dir, but not on subdirectories. File arguments are treated
   normally, of course.

No need to distinguish between `.' and other dirs, they're all just
dirs.

> e.g. svn plist lists props on all immediate children of the current dir,
> whereas svn plist dir lists props only on dir. The only thing I don't like=
> =20
> about this is svn up -n dir. Most people would expect it to do all childre=
> n=20
> of the dir.
>
> What do people think about this?

I think other subdirs under a named target <dir> should not be treated
at all. If the user wanted them, she should name them, or do
recursive.

I realize there's a weird boundary case here, especially in the case
of the property commands, in that an immediate subdir itself might or
might not be presumed to fall within the scope of the command, and CVS
doesn't give us any precedent of course, because it doesn't version
directories. A simple and consistent solution is to say that
non-recursive means "ignore all directories other than the ones
actually specified to the command". Easy to implement, too. :-)

How does that sound?

-K

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:44 2006