ReleaseEngineering/How To/VCSSync

This is documentation on the mozharness-based vcs sync processes.

See Hal's docs for the legacy process.

Maintenance

How to add a project to project-branch conversion

If the project is under hg.m.o/projects, add it here.

If the project isn't under hg.m.o/projects, add it here.

Troubleshooting

How to deal with completely resetting gecko-projects

1. Make the decision that this is the solution to the problem.
2. Make sure people are aware this is going to happen.
3. Stop the conversion of gecko-projects. This is currently on vcs2vcs@vcssync2, and is run via cron.
4. Save a copy of https://raw.github.com/mozilla/integration-gecko-projects/master/README.md
5. Delete the repo! This option is available in the "Danger Zone" area of https://github.com/mozilla/integration-gecko-projects/settings
6. Recreate the repo. There's a "Create a new repo" icon in the top right. This will need the same name, should be public, and you want to initialize the repo with a README.
7. Edit the README with the contents you downloaded in step 4.
8. Start the conversion back up. You may only need to delete the build/target and build/stage_source/BAD_REPO directories. Or you may need to blow away the whole thing from orbit to be sure, in which case you should follow the docs for how to start a mozilla-central based repo conversion from scratch.

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