[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