ReleaseEngineering/How To/VCSSync: Difference between revisions
| 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> | |||
Revision as of 18:27, 14 October 2013
This is documentation on the mozharness-based vcs sync processes.
See Hal's docs for the legacy process.
Emails
Maintenance
How to add a repo to gecko-dev or gecko-git
How to add a project to project-branch conversion
How to add a locale to l10n conversion
How to adjust email notifications
How to force the process to pull/bookmark/convert/push a repo, even if nothing's changed
Troubleshooting
How to deal with non-ffwd
How to deal with project branch reset
How to deal with completely resetting gecko-projects
How to deal with GECKO90_2011121217_RELBRANCH
We were getting email with the following failure:
11:14:01 ERROR - remote: error: denying non-fast-forward refs/heads/GECKO90_2011121217_RELBRANCH (you should pull first) 11:14:01 ERROR - ! [remote rejected] GECKO90_2011121217_RELBRANCH -> GECKO90_2011121217_RELBRANCH (non-fast-forward) 11:14:01 ERROR - error: failed to push some refs to '/opt/vcs2vcs/build/target/beagle/.git' 11:14:02 ERROR - Return code: 256 11:14:02 ERROR - mozilla-beta: Can't push /opt/vcs2vcs/build/conversion/beagle to /opt/vcs2vcs/build/target/beagle/.git! 11:14:02 ERROR - This was a test push that failed; not proceeding any further with mozilla-beta!
To debug:
# vcs2vcs@vcssync1 cd /opt/vcs2vcs/build/target/beagle git show GECKO90_2011121217_RELBRANCH # this gave 1003ec79451969335008880ad82e305d93b89642 cd /opt/vcs2vcs/build/conversion/beagle git show GECKO90_2011121217_RELBRANCH # this gave fac7279c040d643fb4c35105fa85b9335ba2c2f9 git merge-base fac7279c040d643fb4c35105fa85b9335ba2c2f9 1003ec79451969335008880ad82e305d93b89642
The merge-base returned fac7279c040d643fb4c35105fa85b9335ba2c2f9. That means that fac727 is a parent to 1003ec. No sha divergence, only stale history.
I noticed that http://hg.mozilla.org/releases/mozilla-beta/rev/GECKO90_2011121217_RELBRANCH pointed at a9221b332d8a (dec 15) and http://hg.mozilla.org/releases/mozilla-release/rev/GECKO90_2011121217_RELBRANCH pointed at 4e309e63c279 (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:
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