cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <dani...@nada.kth.se>
Subject Re: Temporarily disabling svn fetching of blocks?
Date Fri, 18 Mar 2005 16:18:28 GMT
Reinhard Poetz wrote:

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

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

Doesn't dispute that, I'm talking about the svn:externals in 
cocoon/trunk/src/blocks.

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

We have the svn:externals in cocoon/trunk/src/blocks because its 
convenient right now, but as I describe, there are IMO good reasons for 
moving them to cocoon/blocks-trunk (or some other place *outside* 
cocoon/trunk) instead.

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

Do you understand it now?

> 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

Yes, but that doesn't solve Bertrand's problem described above.

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

Yes, maybe I'm running ahead. Just wanted to point out that the 
svn:externals under trunk isn't a good long term solution.

/Daniel


Mime
View raw message