On 9/22/05, Daniel Rall <dlr@finemaltcoding.com> wrote:
> On Thu, 22 Sep 2005, Tim Shadel wrote:
> ...
> > So it seems important to have a way to say "I don't want this
> > in my working copy anymore. Please don't bring it back
> > unless I ask for it." Since that can only be done
> > by manipulating the .svn\entries file, it has to be a
> > features of svn, and not simply a combination of
> > operating system features and "svn st".
>
> As you mention in the next paragraph, this can also be handled by
> not checking some sub-directories out in the first place.
>
> > 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.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Sep 23 06:28:40 2005