No, Scott's right, I should svn merge rather than commiting a metadata-unrelated patch. Both achieve the desired effect; one establishes the metadata trail. Showing the patch of what's being done for review is separate, and generally not habitual; but then, we don't generally cherrypick merges either, which is why I wanted to advertise it.
On Thu, Dec 11, 2008 at 1:33 PM, Bruce Johnson <br...@google.com> wrote: > @Scott: Blame me. I asked Freeland to take this approach because we are > still urgently trying to stabilize the trunk. We'll knowingly suffer the > cost of a yuckier merge, but we definitely can't take any chance of > additional breakages. > > On Thu, Dec 11, 2008 at 11:42 AM, Scott Blum <sco...@google.com> wrote: > >> 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 <e...@google.com> 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 < >>> gwt.team.fabb...@gmail.com> 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 -~----------~----~----~----~------~----~------~--~---
