[gwt-contrib] Re: review: selective merges from 1.6 to trunk
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 -~--~~~~--~~--~--~---
[gwt-contrib] Re: review: selective merges from 1.6 to trunk
@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 -~--~~~~--~~--~--~---
[gwt-contrib] Re: review: selective merges from 1.6 to trunk
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. Scott's suggestion accomplishes the same thing (and was perhaps how the diff was generated to start with), but specifically merges the particular changes into a working copy preserving the history rather than duplicating the changes. -- John A. Tamplin Software Engineer (GWT), Google --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: review: selective merges from 1.6 to trunk
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 -~--~~~~--~~--~--~---
