[jbosstools-dev] Re: State of SVN and build

[Max Rydahl Andersen]

cc'ed on to jbosstools-dev where this belongs ;)

> 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
>
>