Daniel L. Rall wrote:
> On Thu, 22 Sep 2005, Tim Shadel wrote:
>
>> On 9/22/05, Daniel Rall <dlr@finemaltcoding.com> wrote:
>>> On Thu, 22 Sep 2005, Tim Shadel wrote:
> ...
>>>> I've been using 'svn' since 0.18, so it took me quite
>>>> a while to figure out why this worked in CVS. It is the
>>>> interplay between two commands: 'cvs release -d' nukes
>>>> the directory, and 'cvs update' **unlike svn update**
>>>> will **NOT** bring down missing directories, so you can
>>>> remain isolated until you run 'cvs update -dP' which
>>>> is **much more like svn**. Does that ring any bells?
>>>> So the old 'cvs release -d' CAN be recreated from
>>>> operating system commands, but the svn version cannot.
>>>> Kind of a time warp to recall those details. :-)
>>>
>>> How about using a combination of 'svn co -N URI', 'svn ls URI',
>>> and 'svn co' of desired sub-directories found by 'svn ls'?
>>>
>>
>> That works for selecting my first batch of projects. Your procedure
>> is perfect there. But then next week I'll need a different set. At
>> that point I _no longer_ want some folders that have already been
>> checked out. I can't "undo" an 'svn co' after it's done without
>> hand-editing the .svn\entries.
>
> How about checking out a new working copy? I always use a fresh one when
> doing releng-related work.
But his use-case *isn't* releng-related work - it is normal day-to-day
development, on a modular tree which is too large for it to be sensible to
maintain a full checkout at all times.
The whole nonrecursive checkout thing needs some work, and I agree that one
of those aspects is a way to make subtrees go away, and stay gone in the
face of 'svn update'. I'm not sure whether 'release' is quite the right
verb, but we do need this ability.
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Sep 25 00:19:02 2005