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

Marshall Culpepper marshall.culpepper at redhat.com
Mon Apr 28 17:15:44 EDT 2008


Your suggestions for the branches (and possibly even tags) layouts are 
probably good, there shouldn't be any changes in the config of the build 
system other than using the new naming standard..

As for trunk vs branch coding... If you want to create a component 
branch for 3.3.x compatibility then focus on 3.4/ganymede in trunk the 
build would have no problem with that. I could easily tell releng to 
pull the AS builder from i.e. branches/components/as-3.3.x rather than 
trunk so you can do all your "bleeding edge" you want. It's just a 
matter of you letting me know how/when you want to do such a thing, and 
it's pretty easy to accomplish =).

Max Rydahl Andersen wrote:
> 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
>>
>>
>>     
>
>
>
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20080428/7c50e296/attachment.html 


More information about the jbosstools-dev mailing list