You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@forrest.apache.org by Ross Gardler <rg...@apache.org> on 2005/08/17 16:22:52 UTC
Move eclipse tools out of trunk
Forrests SVN checkout is too large. One way of making it smaller is by
moving the eclipse tools directory out of trunk (10Mb).
Since devs working on the eclipse tools do so independantly of Forrest
this makes sense. In fact, in the new instructions I am writing for
setting up the eclipse platform I am recomending that the tools be
checked out separatly anyway (it just makes sense for Eclipse to do this).
So, I would like to move the Eclipse tools from:
https://svn.apache.org/repos/asf/forrest/trunk/
to:
https://svn.apache.org/repos/asf/forrest/tools/eclipse/trunk
Any ojections?
Ross
Re: Move eclipse tools out of trunk
Posted by Diwaker Gupta <di...@apache.org>.
On Wednesday 17 August 2005 7:22 am, Ross Gardler wrote:
> So, I would like to move the Eclipse tools from:
>
> https://svn.apache.org/repos/asf/forrest/trunk/
>
> to:
>
> https://svn.apache.org/repos/asf/forrest/tools/eclipse/trunk
+1
--
Web/Blog/Gallery: http://floatingsun.net
Re: Move eclipse tools out of trunk
Posted by Ross Gardler <rg...@apache.org>.
Ross Gardler wrote:
> Forrests SVN checkout is too large. One way of making it smaller is by
> moving the eclipse tools directory out of trunk (10Mb).
Anils new daisy plugin adds another 2.5 Mb...
>
> Since devs working on the eclipse tools do so independantly of Forrest
> this makes sense. In fact, in the new instructions I am writing for
> setting up the eclipse platform I am recomending that the tools be
> checked out separatly anyway (it just makes sense for Eclipse to do this).
>
> So, I would like to move the Eclipse tools from:
>
> https://svn.apache.org/repos/asf/forrest/trunk/
>
> to:
>
> https://svn.apache.org/repos/asf/forrest/tools/eclipse/trunk
>
> Any ojections?
>
> Ross
>
>
Re: Trimming SVN checkouts (was Re: Move eclipse tools out of trunk)
Posted by David Crossley <cr...@apache.org>.
Diwaker Gupta wrote:
> On Thursday 18 August 2005 8:21 am, Ross Gardler wrote:
> > core
> > /trunk
> > /branches
> > plugins
> > /org.apache.forrest.input.wiki
> > /trunk
> > /branches
> > /org.apache.forrest.output.pdf
> > /trunk
> > /branches
> > tools
> > /eclipse
> > /trunk
> > /branches
> > /forrestbot
> > /trunk
> > /branches
> > docs
> > /trunk
> > /branches
>
> +1.
>
> I would also add a /tags to each of the sections. However, we might get away
> without it since IIUC projects are *required* to use archive.apache.org for
> older versions?
All of our actual releases *.zip *.tar.gz etc.
are automatically archived to that location.
We keep a branch of each release of trunk, and would
do so for each plugin and tool.
How does tags help?
-David
Re: Trimming SVN checkouts (was Re: Move eclipse tools out of trunk)
Posted by Diwaker Gupta <di...@apache.org>.
On Thursday 18 August 2005 8:21 am, Ross Gardler wrote:
> core
> /trunk
> /branches
> plugins
> /org.apache.forrest.input.wiki
> /trunk
> /branches
> /org.apache.forrest.output.pdf
> /trunk
> /branches
> tools
> /eclipse
> /trunk
> /branches
> /forrestbot
> /trunk
> /branches
> docs
> /trunk
> /branches
+1.
I would also add a /tags to each of the sections. However, we might get away
without it since IIUC projects are *required* to use archive.apache.org for
older versions?
--
Web/Blog/Gallery: http://floatingsun.net
Re: Trimming SVN checkouts (was Re: Move eclipse tools out of trunk)
Posted by Ross Gardler <rg...@apache.org>.
David Crossley wrote:
> Ross Gardler wrote:
>
>>David Crossley wrote:
>>
>>>Ross Gardler wrote:
>>>
>>>
>>>>I've not thought through the implications of this. I'm pretty sure that
>>>>moving tools out is a good idea (notice I suggest a tools subdirectory
>>>>when moving eclipse, that was for a reason ;-) feel free to rubbish the
>>>>idea though (or even agree with it ;-)
>>>
>>>I don't yet see what we gain by doing this, other than
>>>people can checkout certain parts separately.
>>
>>My thinking is that we move all plugins code out of core. Most devs are
>>not interested in most of the plugins, yet they have to checkout
>>everything. Similarly, most devs are not interested in whiteboard or tools.
>
>
> There are a lot of people interested in whiteboard
> at the moment ;-)
Very good point (I assume you mean views).
>>When we consider things like full docbook support in a plugin we will
>>have lots of XSL, DTD etc. from the Docbook project. This will be a
>>pretty large plugin, others may also get pretty large.
>
>
> DocBook is not a good example, because we decided to
> develop a download system for such cases. But yes
> some plugins will grow large because of additional
> jars, or large content like the gallery plugin.
>
>
>>By extracting the plugins, tools, whiteboard etc we enable devs to
>>checkout just the core stuff and any particular parts they want. Hence
>>checkout (and subsequent "svn status" and similar commands) happen
>>quicker. Using svn:external we can still provide a single checkout for
>>those developers who want everything.
>
>
> That is what causes me confusion. When *any* developer
> does an 'svn checkout' of trunk, then they get all the
> pieces anyway. So no benefit regarding volume of data.
> Am i missing something?
It depends how it is set up. We can choose to have *some*
plugins/whiteboard etc. in the "trunk" (i.e. forrest-core) checkout. It
need not be all. We can also provide different checkouts that contain
different sets of tools and plugins (this really is going too far though
I think).
Using views as an example. It could have started life as a set of
plugins in whiteboard *without* an svn:external in forrest-core. Thus it
doesn't get checked out by most devs. However, once it becomes
reasonably stable and people are taking an insterest we can add an
svn:external to forrest-core. SO all devs start getting it.
> One benefit that i do see is that those pieces can
> have separate release cycles and can have branches.
> That also adds a lot of work at release time, but
> it is a lot of work anyway.
Well plugins can already have their own release cycle. Whiteboard items
may never be formally released, but they do have "soft release" by using
svn:external to bring them into core.
What additional work does this add at release time though? If it makes
release management harder we have to balance that against any percieved
development benefits. I'm still undecided, this could result in
splitting things up and dividing the community then again, it may make
it easier for people to start development.
>>Similarly, some devs are not interested in core, but would like to work
>>on docs or on, for example, the OOo plugin. These devs would be able to
>>work on them without having to checkout the full Forrest svn.
>
>
> That is where i can certainly see benefit.
> However, it would be preferable that developers
> work with the current core. I suppose if we have
> proper and automated testing, then we will discover
> inconsistencies.
Plugins can have a different release cycle. Currently there is only one
plugin that has an SVN head version that requires 0.8-dev Plugins should
continue to support the earliest version of Forrest it is possible for
them to support. Therefore there is no need for people to work against
the current core.
However, I do agree that this raises a problem with automated testing.
We have a level of this in that the test target of plugins is run
whenever a plugin is deployed. However, this has problems in that the
test may not be complete (i.e. not all features are present) and it may
not be tested against the Forrest version claimed to be supported. (I'll
raise an issue about this).
Ross
Re: Trimming SVN checkouts (was Re: Move eclipse tools out of trunk)
Posted by David Crossley <cr...@apache.org>.
Ross Gardler wrote:
> David Crossley wrote:
> >Ross Gardler wrote:
> >
> >>I've not thought through the implications of this. I'm pretty sure that
> >>moving tools out is a good idea (notice I suggest a tools subdirectory
> >>when moving eclipse, that was for a reason ;-) feel free to rubbish the
> >>idea though (or even agree with it ;-)
> >
> >I don't yet see what we gain by doing this, other than
> >people can checkout certain parts separately.
>
> My thinking is that we move all plugins code out of core. Most devs are
> not interested in most of the plugins, yet they have to checkout
> everything. Similarly, most devs are not interested in whiteboard or tools.
There are a lot of people interested in whiteboard
at the moment ;-)
> When we consider things like full docbook support in a plugin we will
> have lots of XSL, DTD etc. from the Docbook project. This will be a
> pretty large plugin, others may also get pretty large.
DocBook is not a good example, because we decided to
develop a download system for such cases. But yes
some plugins will grow large because of additional
jars, or large content like the gallery plugin.
> By extracting the plugins, tools, whiteboard etc we enable devs to
> checkout just the core stuff and any particular parts they want. Hence
> checkout (and subsequent "svn status" and similar commands) happen
> quicker. Using svn:external we can still provide a single checkout for
> those developers who want everything.
That is what causes me confusion. When *any* developer
does an 'svn checkout' of trunk, then they get all the
pieces anyway. So no benefit regarding volume of data.
Am i missing something?
One benefit that i do see is that those pieces can
have separate release cycles and can have branches.
That also adds a lot of work at release time, but
it is a lot of work anyway.
> Similarly, some devs are not interested in core, but would like to work
> on docs or on, for example, the OOo plugin. These devs would be able to
> work on them without having to checkout the full Forrest svn.
That is where i can certainly see benefit.
However, it would be preferable that developers
work with the current core. I suppose if we have
proper and automated testing, then we will discover
inconsistencies.
-David
Re: Trimming SVN checkouts (was Re: Move eclipse tools out of trunk)
Posted by Ross Gardler <rg...@apache.org>.
David Crossley wrote:
> Ross Gardler wrote:
>
>>I've not thought through the implications of this. I'm pretty sure that
>>moving tools out is a good idea (notice I suggest a tools subdirectory
>>when moving eclipse, that was for a reason ;-) feel free to rubbish the
>>idea though (or even agree with it ;-)
>
>
> I don't yet see what we gain by doing this, other than
> people can checkout certain parts separately.
My thinking is that we move all plugins code out of core. Most devs are
not interested in most of the plugins, yet they have to checkout
everything. Similarly, most devs are not interested in whiteboard or tools.
When we consider things like full docbook support in a plugin we will
have lots of XSL, DTD etc. from the Docbook project. This will be a
pretty large plugin, others may also get pretty large.
By extracting the plugins, tools, whiteboard etc we enable devs to
checkout just the core stuff and any particular parts they want. Hence
checkout (and subsequent "svn status" and similar commands) happen
quicker. Using svn:external we can still provide a single checkout for
those developers who want everything.
Similarly, some devs are not interested in core, but would like to work
on docs or on, for example, the OOo plugin. These devs would be able to
work on them without having to checkout the full Forrest svn.
Ross
Re: Trimming SVN checkouts (was Re: Move eclipse tools out of trunk)
Posted by David Crossley <cr...@apache.org>.
Ross Gardler wrote:
>
> I've not thought through the implications of this. I'm pretty sure that
> moving tools out is a good idea (notice I suggest a tools subdirectory
> when moving eclipse, that was for a reason ;-) feel free to rubbish the
> idea though (or even agree with it ;-)
I don't yet see what we gain by doing this, other than
people can checkout certain parts separately.
-David
Trimming SVN checkouts (was Re: Move eclipse tools out of trunk)
Posted by Ross Gardler <rg...@apache.org>.
David Crossley wrote:
> Ross Gardler wrote:
>
>>Forrests SVN checkout is too large. One way of making it smaller is by
>>moving the eclipse tools directory out of trunk (10Mb).
>>
>>Since devs working on the eclipse tools do so independantly of Forrest
>>this makes sense. In fact, in the new instructions I am writing for
>>setting up the eclipse platform I am recomending that the tools be
>>checked out separatly anyway (it just makes sense for Eclipse to do this).
>>
>>So, I would like to move the Eclipse tools from:
>>
>>https://svn.apache.org/repos/asf/forrest/trunk/
>>
>>to:
>>
>>https://svn.apache.org/repos/asf/forrest/tools/eclipse/trunk
>>
>>Any ojections?
>
>
> Not from me. We have got to find ways to shed the weight.
> Plugins is the next thing to investigate.
>
> I am not sure if this is related ...
> Does someone understand what Cocoon did with their
> SVN using svn:externals? They separated the blocks
> away from the core. Does that technique help us?
Yes, I've been exploring this. What happens is you can create a separate
repo for parts like the tools folder, the plugins, the whiteboard,
forrest core etc.
Devs can then checkout the parts they need, i.e. just the eclipse tools.
You can create new repos that contain pointers to these external repos
using svn:external. When you checkout such a repo it will automatically
ceckout the external ones.
In Cocoon they have created separated replos for all the blocks and put
svn:externals into core. This means that when you checkout core you bet
all the blocks as well, therefore it does not reduce the size of the
core checkout and so I'm not sure of the advantage.
I'm using svn:external to checkout the portal block from cocoon into my
local forrest directory (work has stalled on that - don't get excited)
Off the top of my head we could (in the long term) do something like the
following under https://svn.apache.org/repos/asf/forrest/:
core
/trunk
/branches
plugins
/org.apache.forrest.input.wiki
/trunk
/branches
/org.apache.forrest.output.pdf
/trunk
/branches
tools
/eclipse
/trunk
/branches
/forrestbot
/trunk
/branches
docs
/trunk
/branches
Notice how each section has its own trunk and branches (thinking back to
our discussion about using branches to manage development).
Then, to facilitate developers working on integration testing and the
like we could have:
https://svn.apache.org/repos/asf/forrest/
/trunk
/branches
This would use svn:export to recreate the same repo structure we have
now, but without the tools directory which is essentially sub projects
that happen to use Forrest. In other words, what you get out of SVN when
requesting https://svn.apache.org/repos/asf/forrest/trunk (i.e. the same
URL as today) is the complete checkout of Forrest.
I've not thought through the implications of this. I'm pretty sure that
moving tools out is a good idea (notice I suggest a tools subdirectory
when moving eclipse, that was for a reason ;-) feel free to rubbish the
idea though (or even agree with it ;-)
Ross
Re: Move eclipse tools out of trunk
Posted by David Crossley <cr...@apache.org>.
Ross Gardler wrote:
> Forrests SVN checkout is too large. One way of making it smaller is by
> moving the eclipse tools directory out of trunk (10Mb).
>
> Since devs working on the eclipse tools do so independantly of Forrest
> this makes sense. In fact, in the new instructions I am writing for
> setting up the eclipse platform I am recomending that the tools be
> checked out separatly anyway (it just makes sense for Eclipse to do this).
>
> So, I would like to move the Eclipse tools from:
>
> https://svn.apache.org/repos/asf/forrest/trunk/
>
> to:
>
> https://svn.apache.org/repos/asf/forrest/tools/eclipse/trunk
>
> Any ojections?
Not from me. We have got to find ways to shed the weight.
Plugins is the next thing to investigate.
I am not sure if this is related ...
Does someone understand what Cocoon did with their
SVN using svn:externals? They separated the blocks
away from the core. Does that technique help us?
-David