You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Bertrand Delacretaz <bd...@apache.org> on 2005/03/18 15:01:28 UTC
Temporarily disabling svn fetching of blocks?
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 ;-)
-Bertrand
Re: Temporarily disabling svn fetching of blocks?
Posted by Tim Larson <ti...@keow.org>.
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
Re: Temporarily disabling svn fetching of blocks?
Posted by Reinhard Poetz <re...@apache.org>.
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
--------------------------------------------------------------------
Re: Temporarily disabling svn fetching of blocks?
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
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
Re: Temporarily disabling svn fetching of blocks?
Posted by Reinhard Poetz <re...@apache.org>.
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
--------------------------------------------------------------------
Re: Temporarily disabling svn fetching of blocks?
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
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.
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.
/Daniel