cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Poetz <reinh...@apache.org>
Subject Re: Temporarily disabling svn fetching of blocks?
Date Fri, 18 Mar 2005 15:37:10 GMT
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. 

IMO blocks should go to

/cocoon/blocks/[name]/trunk

> It will create some slight inconvinience at the 
> beginning as one must check out two directories instead of one 

Why?

> and as we 
> have to update the build system somewhat.
> But there are a number of advantages:
> 
> It will solve the problem you are facing, you just update the blocks you 
> are interested in, an update of cocoon/trunk will not affect any blocks. 
> If there are a group of blocks that you always want to update you can 
> create a folder and use svn propedit to make external links to those 
> blocks (see http://wiki.rubyonrails.com/rails/show/EdgeRails for an 
> example). Subdirectories for core, supported and contributed would IMO 
> have been natural groups of blocks that you might have wanted to update 
> together, but you obviously prefered not to ;)
> 
> It will make it easier for projects like Forrest and Lenya, they can 
> just make external links to cocoon/trunk and the blocks that they need. 
> But maybe SVN doesn't follow externals in external projects so that its 
> not a problem anyway. We probably also want to support the scenario 
> where we have an external link to a Forrest block (for simplifying 
> doco), while the Forrest block might have an external link to Cocoon (to 
> simplify their development).
> 
> Also it will motivate us to make it easy to handle external blocks, as 
> all our own blocks become external.

Sorry, after reading your mail I'm not sure if I understand you. Currently 
blocks are in /cocoon/blocks/[status]/[block-name]/trunk. After our discussion 
the majority was in favour of having only /cocoon/blocks/[block-name]/trunk.

Cocoon trunk (/cocoon/trunk/) could have a svn:external property set in 
(/cocoon/trunk/src/) that points to

blocks	https://svn.apache.org/repos/asf/cocoon/blocks

and all blocks are included. This would require a minor build system 
modification as (reflect that a block is in a trunk directory).

As long as we don't have branches and tags on blocks this is a working solution. 
  I hope that by then we have a working block building and deployment system 
that doesn't require any SVN tricks.

-- 
Reinhard Pötz           Independent Consultant, Trainer & (IT)-Coach 

{Software Engineering, Open Source, Web Applications, Apache Cocoon}

                                        web(log): http://www.poetz.cc
--------------------------------------------------------------------

Mime
View raw message