forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Crossley <>
Subject Re: Trimming SVN checkouts (was Re: Move eclipse tools out of trunk)
Date Tue, 23 Aug 2005 00:51:49 GMT
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


View raw message