Wow Mike. I'm sure one day we'll need to do all of that. However, for now. We have 3-5 guys working on pretty short lived releases and branches. Thus I think the simplest thing that works is probably best. For now lets just do this.
Branches happen along releases (M1RC1, RC2, M1FINAL all on the same branch). Tags are for releases (M1RC1, M1RC2, M1FINAL) Changes which affect both releases should be made in the release branch and ALSO applied to the other branch. No merging should happen unless the FINAL release has happened. (Too big of a pain to branch/unbranch/rebranch/etc). Rationale: Its not that much trouble to apply the few bug fixes that we'll likely apply before M1FINAL happens (and I don't expect an M1RC2) also to head. Collisions are unlikely even on large projects, they're really unlikely for us. I'm the most likely collider as I'm probably hte most cross functional, but I kind of go from Code-boy to Doc-boy to Release-boy in cycles so even then I'm predictable. Thus this is simpler. We can invoke a more robust system if problems pop up or the project grows. I'd love us to have the problem of too many coders stepping on each others toes in CVS :-) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3831935#3831935 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3831935 ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
