Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: pass (hermes.apache.org: local policy)
Date: Fri, 18 Mar 2005 16:31:00 +0000
From: Tim Larson <tim@keow.org>
To: dev@cocoon.apache.org
Subject: Re: Temporarily disabling svn fetching of blocks?
Message-ID: <20050318163100.GG23086@localhost>
References: <1ddafac7dc5cb2787a7239b37c551285@apache.org>
 <423AEF36.1010204@nada.kth.se>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <423AEF36.1010204@nada.kth.se>
User-Agent: Mutt/1.5.6+20040907i

On Fri, Mar 18, 2005 at 04:09:42PM +0100, Daniel Fagerstrom wrote:
> Bertrand Delacretaz wrote:
> 
> >With the new blocks structure, running "svp up" causes a lot of 
> >messages like
> >
> >  Fetching external item into 'src/blocks/paranoid'
> >  Updated external to revision 158070.
> >
> >Which slows down the "svn up" a lot.
> >
> >Is there an easy way to tell svn to ignore some blocks for a while?
> 
> Not that I know, but I'm not an SVN expert.
> 
> >My gut feeling is that there must be a very easy solution right in 
> >front of my eyes, but I cannot see it ;-)
> 
> There is, we should move the cocoon/trunk/src/blocks to 
> cocoon/blocks-trunk. It will create some slight inconvinience at the 
> beginning as one must check out two directories instead of one and as we 
> have to update the build system somewhat.

Here is an odd thought: What if we made the Cocoon core be a block,
at least in terms of how we layout the svn directory structure?
This goes with the idea of all blocks being external blocks.

Then (if we wanted to) we could create various directories containing
svn:external's to bring in specific versions or branches of the core
and selected blocks...to create sets which include blocks which work
well together (for release bundles, to mark supported blocks via the
file system, etc.)

--Tim Larson