[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-27 00:29:16 CEST

On Sat, 24 Sep 2005, Max Bowsher wrote:

> Daniel L. Rall wrote:
> >On Thu, 22 Sep 2005, Tim Shadel wrote:
> >
> >>On 9/22/05, Daniel Rall <dlr@finemaltcoding.com> wrote:
...
> >>>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.
 
Okay -- I've certainly run into this before. I use a system built on top
of Subversion which allows me to check out only portions of my tree at a
time. It's implemented using 'svn switch' to empty directories for those
that I do not want to pull down content for -- perhaps Tim could use
something along those lines.

> 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.

Agreed.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Sep 27 00:28:49 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.