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

Re: recursive/nonrecursive

From: Karl Fogel <kfogel_at_newton.ch.collab.net>
Date: 2002-07-04 19:12:48 CEST

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 <sussman@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
Received on Thu Jul 4 19:22:56 2002

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.