Confirmed users
4,971
edits
ReleaseEngineering/How To/VCSSync: Difference between revisions
ReleaseEngineering/How To/VCSSync (view source)
Revision as of 18:27, 14 October 2013
, 14 October 2013→How to deal with GECKO90_2011121217_RELBRANCH
| Line 50: | Line 50: | ||
The merge-base returned <code>fac7279c040d643fb4c35105fa85b9335ba2c2f9</code>. That means that <code>fac727</code> is a parent to <code>1003ec</code>. No sha divergence, only stale history. | The merge-base returned <code>fac7279c040d643fb4c35105fa85b9335ba2c2f9</code>. That means that <code>fac727</code> is a parent to <code>1003ec</code>. No sha divergence, only stale history. | ||
# | |||
I noticed that http://hg.mozilla.org/releases/mozilla-beta/rev/GECKO90_2011121217_RELBRANCH pointed at <code>a9221b332d8a</code> (dec 15) and http://hg.mozilla.org/releases/mozilla-release/rev/GECKO90_2011121217_RELBRANCH pointed at <code>4e309e63c279</code> (jan 3); Calendar must have done a release off the relbranch off mozilla-release. Since the branch name is shared across mozilla-beta and mozilla-release, converting the branch from mozilla-beta effectively does a non-fastforward push and is rejected. | |||
To fix, I exported the two revisions from mozilla-release to mozilla-beta: | |||
<pre> | |||
cd mozilla-release | |||
hg export -r 79350 > ../cal2 | |||
hg export -r 79349 > ../cal1 | |||
# Doublecheck to make sure those look good | |||
cd ../mozilla-beta | |||
hg pull -u | |||
hg up -r GECKO90_2011121217_RELBRANCH | |||
hg import ../cal1 | |||
hg ident # sha matched m-r | |||
hg import ../cal2 | |||
hg ident # sha matched m-r | |||
hg out | |||
hg push | |||
</pre> | |||