Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: neutral (hermes.apache.org: local policy)
Message-ID: <423B00E2.2020806@apache.org>
Date: Fri, 18 Mar 2005 17:25:06 +0100
From: Reinhard Poetz <reinhard@apache.org>
User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: Temporarily disabling svn fetching of blocks?
References: <1ddafac7dc5cb2787a7239b37c551285@apache.org>
 <423AEF36.1010204@nada.kth.se> <423AF5A6.2050808@apache.org>
 <423AFF54.8030302@nada.kth.se>
In-Reply-To: <423AFF54.8030302@nada.kth.se>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Daniel Fagerstrom wrote:
> 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?

yes, got it. Then we have

/cocoon/trunk
/cocoon/blocks
/cocoon/blocks-trunk

and /cocoon/blocks-trunk points to all blocks. Yes, good idea!

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

no, no, you're right.

BTW, in your mail you asked whether we can point to other projects in SVN or 
not. I'm not aware of any resons that prevents this. We already agreed that we 
want to integrate excalibur sources this way. But we have to think about it how 
we do it as otherwise it might slow down svn up again.

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

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

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