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

Marshall Culpepper marshall.culpepper at redhat.com
Mon Apr 28 20:36:43 EDT 2008


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.



More information about the jbosstools-dev mailing list