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

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

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

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