Not all of the changes are incompatible. If it was easier to incrementally merge, then the overall problem would have been much less.
For example, if we periodically merged trunk into 1.1, always keeping 1.1 up to date wrt changes on trunk, then the merge back would have been mostly painless and quite easy to perform. --jason On 5/8/06, David Jencks <[EMAIL PROTECTED]> wrote:
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
