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

Re: REQ: svn release

From: Daniel Rall <dlr_at_finemaltcoding.com>
Date: 2005-09-23 02:12:12 CEST

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'?

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Sep 23 02:11:46 2005

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.