Freeland: I would strongly prefer that you literally svn merge c4298 and c4299 from 1.6 into trunk. This will reduce the likelihood of later conflicts. Also, please record they've already been merged in 1.6/branch-info.txt.
(in trunk) svn merge -c4298 https://google-web-toolkit.googlecode.com/svn/releases/1.6 svn merge -c4299 https://google-web-toolkit.googlecode.com/svn/releases/1.6 svn commit -m "Cherry pick merging c4298,c4299 from releases/1.6 to trunk" Also, feel free to do the opposite to merge trunk-c4266 into 1.6. Emily: 1.6 needs to be writeable, we just need to be careful about merges up. On Thu, Dec 11, 2008 at 9:24 AM, Emily Crutcher <[EMAIL PROTECTED]> wrote: > LGTM. Should we freeze new commits to 1.6 until the rest of this shakes > out? > > > On Thu, Dec 11, 2008 at 12:30 AM, Freeland Abbott < > [EMAIL PROTECTED]> wrote: > >> This is going to make our next 1.6 -> trunk merge mildly unpleasant, but >> we need the 1.6 fixes at c4298 and c4299 'cause we're seeing them in the >> trunk, but want minimal other changes until we're sure the current mess >> around the confluence of event updates, hosted mode, war mode, AND oophm >> have settled. (Can we institute a one-a-week or one-a-fortnight policy for >> "big" merges? I trust tests, but I trust tests-and-shakeout-time more... >> and Issac, here's a case where we *are* hiding something; I can't cite the >> code that's gotten messy: it's not GWT's code, and it's not open source.) >> Attached patch is meant to replicate 1.6 4298:4299, only, onto trunk. >> >> Note, in a similar messy-merge bit, that trunk c4266 also needs to >> down-merge at some point. >> >> > > > -- > "There are only 10 types of people in the world: Those who understand > binary, and those who don't" > --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
