cc'ed on to jbosstools-dev where this belongs ;) > Since this release is moving forward, I figured while we all wait for > builds and prepare our next set of goals, we should take a quick look at > the state of our svn and how it relates to our builds. > > I'm going to suggest something, and fully expect to get shot down, which > is fine ;) But since I'm just sitting here waiting for the ganymede > branch to check out, I think it's a fine use of my time. > > 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). The second type is actual release branches... > such as jbosstools-2.1.x. These are for release and *must* be kept around. > > 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. > > 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 > > 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. > > ** Obviously any change in this structure would require a similar change > of the appropriate properties in the build. > > 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. 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. > > 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. > > If this is by design, and we want it this way to keep us all on track > and on the same page, I can completely understand. However it was my > understanding that JBoss Tools would allow for individual releases of > the components and individual components to move forward bleeding edge > if they wanted. > > Any input here is welcome. Below is a list of branches and how I think I > would organize them if SVN were to be re-worked a bit. > > - Rob Stryker > -------- > > 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 > > >

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

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

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

as/trunk/ branches/ hibernate/trunk branches

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.

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

Please don't. Wether you do your new development in a new branch or in head makes zero extra work for you - but if trunk becomes inconsistent it gives alot of extra work to everyone working across the projects (which most of us do)

Marshall - if we do that trunk becomes inconsistent and we loose the current *valuable* setup where we can just checkout trunk.

The day every/most component are doing this then lets come back to it. Right now the current setup it is the simplest that work.

> 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