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

Rob Stryker rob.stryker at redhat.com
Mon Apr 28 20:42:48 EDT 2008


Marshall Culpepper wrote:
> Rob Stryker wrote:
>>
>>> Nothing prevented you from doing a component specific tag/branch for 
>>> your experimental work.
>>>   
>> Except the idea that I shouldn't ever have to work in a *branch* to 
>> do forward dev on my own components that *I* own. Obviously if it's a 
>> shared component, the way xulrunner was introduced, a branch is 
>> necessary. But when I'm the owner of a component, I should be able to 
>> push my forward-progress (or experimental as you call it) in HEAD.
>>
> And there's nothing stopping you from building your 
> Ganymede-bleeding-edge code in trunk. Just let us know before you do 
> so we can point the build at the proper "3.3" branch so nightlies work 
> as expected.
>>> 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
>>>   
>> You misunderstood me here. I didn't want *all* components first 
>> always. What I meant was that that would be where a component could 
>> branch itself:  branch/components/astools.   The HEAD of those 
>> components would still be in TRUNK. but they could all theoretically 
>> target different things. I realize this is less than ideal, so I'm 
>> open to suggestion.
>>
>>
>> For example:
>> |- trunk
>>     |- as (targeting 3.4)
>>     |- seam (targeting 3.3)
>> |- branches
>>    |- releases
>>        |- jbosstools2.1
>>        |- jbosstools2.2
>>    |- workspace
>>        |-  maxs_happy_fun_branch
>>    |- components
>>        |- as
>>          |- jbosstools2.1_maintenance
>>
>> As you can see, the component has it's HEAD section up in TRUNK where 
>> it belongs.
>>
>>
>>
>>> as/trunk/
>>>    branches/
>>>
>>> hibernate/trunk
>>>           branches   
>> Ugh no yuck ;) I agree with you. You need to be able to check out all 
>> from trunk.  But what I'm saying is what's in TRUNK might all be 
>> targeting different things. I as a component lead would like to be 
>> able to move forward my future dev in the "trunk/as" section, and 
>> just inform marshall that jboss tools, which is merely an aggragator, 
>> should use "branches/components/as/jbosstools2.1_maintenance" for the 
>> current builds.
> +1, that's fine. Just let me know
>>
>> But of course this also means that if someone does check out trunk, 
>> there is no guarantee it will all compile together as each of the 
>> trunk portions of the component could be targeting different drivers. 
>> So to get a successful build, they'd have to check out all from trunk 
>> and then replace the ones that have moved forward with their branches 
>> that stopped at current dev.
>>
>> Obviously this is just as complicated and what you're trying to avoid.
>>
>> I can be swayed to keep my HEAD at current jbds driver levels and do 
>> my future dev in a branch, SO LONG AS the branches folder is neat and 
>> organized and I have my own component folder there 
>> (branches/components/as/futureDevGanymede) for example.  This way I 
>> don't have to worry about coliding with other obscure names that may 
>> follow no apparent convention =P
> Releng doesn't care if bleeding-edge dev goes in trunk or a new 
> branch, it's all the same. That being said, we offer nightly builds 
> for a reason... if a potential contributor wants to look at the latest 
> and greatest for a specific version, maybe we should start providing 
> PSFs again to automate the code checkout process.

Ok... so I vote for the creation of the following structure:
  trunk
  trunk/as  (holds whatever I want... bleeding edge or not so long as I 
communicate with jboss tools)
  branches
  branches/releases
  branches/releases/release1
  branches/releases/release2
  branches/workspace
  branches/workspace/ganymede
  branches/components/
  branches/components/as
  branches/components/as/my_jboss_tools_2.1_maintenance_branch

I also vote that the following branches be removed as outdated. 

** If any of these branches are still in active use, PLEASE SAY 
something! **

>      |-  before_xulrunner
>      |-  jbosstools_xulrunner
>      |-  before-eclipse-3.3
>      |-  jboss
>      |-  JBW_BERLIN_2006_BRANCH
>      |-  REWRITE_2007_16_4


- Rob Stryker




More information about the jbosstools-dev mailing list