On May 8, 2006, at 12:03 PM, Jason Dillon wrote:
I agree this maybe the best option given the circumstances, but in
the future we should avoid this mess by reducing branch usage for
only isolated unstable feature work.... Or get an SCM that can
handle merging.
It should be possible to have seperate development branches and
then be able to safly merge them. IMO it is a massive problem with
Subversion that it can not handle this... :-(
What merge support is missing from svn? I don't know of any
automated tool that can take 2 disparate lines of development with
incompatible semantics and merge them.
The problem would have been smaller if we had abandoned 1.1 and built
the configid branch off of trunk, but we would still have to actually
look at all the changes between the branches.
thanks
david jencks
--jason
-----Original Message-----
From: Jeff Genender <[EMAIL PROTECTED]>
Date: Sun, 07 May 2006 09:04:13
To:dev@geronimo.apache.org
Subject: Re: Thinking about 1.2 and moving forward
+1. I think trying to merge 1.1 to the current 1.2 trunk would be a
nightmare, indeed. Moving aside 1.2 and making the 1.1 copy a new
trunk
is the best decision, IMHO.
Matt Hogstrom wrote:
I think we're at the point where 1.1 needs to bake for a bit and
we'll
release it in a few weeks. Since I expect that folks will want to
get to
putting in new feature and functions for 1.2 I wanted to kick off a
thread to get that discussion going.
I'm consolidating here my recollections of discussion on the list
about
what to do. The idea that made the most sense to me was to move the
current trunk to another branch and copy the 1.1 branch to trunk.
We'd
then have people merge their changes from the the old trunk to the
new
and start on 1.2.
I'm not sure about timing but it might be nice to have this work done
before Java One and the hackathons.
Thoughts?
Matt
