Since this release is moving forward, I figured while we all wait for
builds and prepare our next set of goals, we should take a quick look at
the state of our svn and how it relates to our builds.
I'm going to suggest something, and fully expect to get shot down, which
is fine ;) But since I'm just sitting here waiting for the ganymede
branch to check out, I think it's a fine use of my time.
It seems we have several types of branches, in a general sense. Some of
them are temporary branches where someone is working on something at
their leisure. An example of this branch would be before_xulrunner, or
ganymede, which then had to be merged back in eventually (or not, up to
the brancher obviously). The second type is actual release branches...
such as jbosstools-2.1.x. These are for release and *must* be kept around.
The third, arguably, which may not exist yet, would be individual
component branches for releases / maintenance. Let's not forget one of
the promises of the productization of the product was to allow
individual components to move forward as they want. I'll tackle this
type later. For now, let's just accept that this type could (possibly)
exist.
The first thing I notice is that the "branches" section of our svn has
no sub-directories for type of branch. Now perhaps this is by design,
and standard, but I think it would be prudent to have three primary
subdirectories to "branches", specifically:
- temporary / working / toBeMerged / some other name
- releases
- components
All of the individual branches could then be shoved into one of these
three folders. In this way, our branch section would be much cleaner. We
would easily be able to get rid of branches that are outdated or clearly
temporary. Rather than just having one big "branches" folder with all
sorts of garbage thrown in, it would bring a sense of order to the madness.
** Obviously any change in this structure would require a similar change
of the appropriate properties in the build.
The next question I have, though, relates to how build and svn interact.
As of now, it would be impossible for me to make my HEAD / TRUNK for
ASTools use ganymede without breaking the build (assuming every other
plugin stays behind using the older plugins). I would argue that this
is a bad situation. I would argue that I should be able to make my
bleeding-edge code use something brand new while my component's
contribution to JBoss Tools (and nightly builds) is still the old branch
/ tag.
For example, I've known for over a month now that there were severe
changes to the Server Tools actions in ganymede, but I was unable to do
anything to fix it because I wasn't able to focus my main development
forward on that stream. My nightly build contributions would be sucked
into the JBDS and JBossTools tags, and then the fact that JBDS was using
wtp 2.x and I was using 3.x would cause errors.
If this is by design, and we want it this way to keep us all on track
and on the same page, I can completely understand. However it was my
understanding that JBoss Tools would allow for individual releases of
the components and individual components to move forward bleeding edge
if they wanted.
Any input here is welcome. Below is a list of branches and how I think I
would organize them if SVN were to be re-worked a bit.
- Rob Stryker
--------
branches
|- temporary
|- before_xulrunner
|- jbosstools_xulrunner
|- before-eclipse-3.3
|- ganymede
|- jboss
|- JBW_BERLIN_2006_BRANCH
|- REWRITE_2007_16_4
|- release
|- jbosstools-2.0.x
|- jbosstools-2.1.x
|- TOOLS_3_1_0_BETA4_branch
|- TOOLS_3_1_0_BETA5a_branch
|- components
|- IDE_AOP_DEVELOPER_1_1_2_branch
|- IDE_CORE_1_6_0_branch
|- IDE_EJB3_TOOLS_1_0_2_branch
|- IDE_RELENG_ECLIPSE31
|- IDE_TESTS_ECLIPSE31