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

[Max Rydahl Andersen]

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

I actually forgot I created a place for these "experiments".
It's in /workspace and there is one called "max" I created last time I did something crazy.

I should actually have put ganymede in there. My bad.

> The second type is actual release branches...
>> such as jbosstools-2.1.x.  These are for release and *must* be kept around.

yup.

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

sure.

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

That is by design since most svn tools expect it this way.

What we could have done alternatively is to have the components at the higher level and
have trunk/branches below that.

e.g.

as/trunk/
   branches/

hibernate/trunk
          branches 

etc.

Then it would be component driven instead of "all" driven.

Let me tell why I initially pushed for the current model.

I can do this svn co <...>/trunk and have the whole thing. 

If it was split out it would be a nightmare....

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

Well, we could start by deleting non-relevant branches. It is nowhere near being cluttered compared
to other projects ;)

>> ** Obviously any change in this structure would require a similar change
>> of the appropriate properties in the build.

Yes - and going back in time is really hard ;)

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

Nothing prevented you from doing a component specific tag/branch for your experimental work.

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

That is possible today, but as long as things are not 100% decoupled keeping trunk
in sync with what the upcoming JBossTools release is building against would be my
preferred way of doing things.

If some component want to spinoff then that is easy.

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

Do a branch...nothing prevents you from doing that...and you would have to do that anyway
so no extra work. Not sure what your point is ? :)

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

My suggestion:

>> branches
>>  |- release
>>      |-  jbosstools-2.0.x
>>      |-  jbosstools-2.1.x
>>      |- 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
>>      |- TOOLS_3_1_0_BETA4_branch
>>      |- TOOLS_3_1_0_BETA5a_branch
>>  |-  workspace
>>      |-  ganymede

For any new component branches you could do that in /tags/<componentname>/<version> and /branches/<componentname>/<version>..just a suggestion.

...or convince me that if we put components first in svn we can still easily get a checked out project without having
a complex wiki page explaining what is needed to checkout the code.

/max