forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <rgard...@apache.org>
Subject Re: Trimming SVN checkouts (was Re: Move eclipse tools out of trunk)
Date Thu, 25 Aug 2005 21:58:36 GMT
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

Mime
View raw message