Sheriffing/How To/Unified Repos

Unified Repos

I(KWierso)'ll clean this up as I go. Rough IRC logs for now.

Setting up the repo

• http://mozilla-version-control-tools.readthedocs.org/en/latest/hgmozilla/unifiedrepo.html
• https://mozilla-version-control-tools.readthedocs.org/en/latest/hgmozilla/firefoxtree.html

Here's how I set it up:

• Install Mercurial 3.2 or higher
• Make a copy of your .hgrc file for safekeeping and delete the original
• hg clone https://hg.mozilla.org/mozilla-central
• hg clone https://hg.mozilla.org/hgcustom/version-control-tools
• cd mozilla-central
• ./mach mercurial-setup
  • Configure mercurial as desired (do not enable the mq extension)
• Edit your global .hgrc file to add the following to the [extensions] section:
  • firefoxtree = /path/to/version-control-tools/hgext/firefoxtree
• The following will pull all (or at least most) of the branches sheriffs need to have on hand:
  • hg pull inbound && hg pull b2ginbound && hg pull fx-team && hg pull aurora && hg pull beta && hg pull esr31 && hg pull b2g34 && hg pull b2g32 && hg pull b2g30
  • If you need other branches, you can find their names in the firefoxtree extension source.

You should now have everything set up for proper use! The `hg fxheads` command should list references to each of the relevant branch names, and the current revision and commit message for each.

Merges

This assumes you have your unified repo all set up so that `hg fxheads` lists each of central, b2ginbound, fx-team, and inbound.

To merge a specific non-tip <revision> from mozilla-inbound to mozilla-central:

1. hg pull central
2. hg pull inbound
3. hg up central
4. hg merge -r <revision>
5. hg commit -m "Merge mozilla-inbound to mozilla-central a=merge"
6. hg push -r . central

To merge mozilla-central into mozilla-inbound:

1. hg pull central
2. hg pull inbound
3. hg up inbound
4. hg merge central
5. hg commit -m "Merge mozilla-central to mozilla-inbound a=merge"
6. hg push -r . inbound

• If the `hg merge central` command results in "abort: nothing to merge", you should instead use `hg update -r <mozilla-central's tip revision>` to do a non-merging update, then you can do `hg push -r . inbound` to push it as usual.

Rebasing after losing a push race

This assumes you have commits you're attempting to push to mozilla-inbound when you lose a push race with someone. Change `inbound` to the correct branch name as needed.

• hg pull inbound
• hg rebase -d inbound
• hg push -r . inbound

Recovering from mistakes

• [20:55] KWierso gps: actually, one last question :)
• [20:56] KWierso at the moment with all of the separate repositories, cleaning up stuff that's not right is some combination of | hg pull -u | and | hg strip | to get rid of non-pushed local changes and bring in newly-pushed things
• [20:57] KWierso how would I do that in a unified repo?
• [21:05] gps KWierso: generally speaking, if you have to "clean up stuff that's not right," that's probably a sign you are doing something wonky
• [21:06] gps i rarely find myself running `hg strip`
• [21:06] gps although that's partially because i use evolve
• [21:07] gps running `hg strip` in a shared repo is somewhat dangerous. if another working copy is using changesets that were stripped, that could corrupt the working copy
• [21:07] gps if you have old screw-ups, it's best to leave them be
• [21:07] gps if you have evolve, you can `hg prune <rev>` to mark them hidden
• [21:07] gps they kinda just vanish, without the bad consequences
• [21:10] gps as long as you don't have a shared repo referencing commits that you strip, you should be OK
• [21:10] gps e.g. if you `hg pull` and then want to `hg strip` what you just pulled, that's fine
• [21:10] gps but if you go back in history and start removing random things, watch out!
• [21:11] KWierso gps: I probably should have put the whole command, not just "hg strip"
• [21:11] KWierso | hg strip --no-backup 'roots(outgoing())' |
• [21:12] gps well, if you have a unified repo, outgoing() will report changesets from all repos, and that will almost certainly strip a lot of commits!
• [21:12] gps depending on what you've pulled, of course
• [21:13] gps if you have aurora and central in the same repo and out outgoing against central, all aurora commits will be in that set
• [21:13] KWierso ick
• [21:14] gps |not public()| may be a better selector
• [21:14] gps but that assumes you don't have any local commits that haven't landed yet
• [21:15] KWierso most of the time for sheriffing-related stuff, it's not our own commits, but stuff we're checking in for others or uplifting
• [21:16] KWierso so it's stuff others already put up in patches on bugzilla or landed on m-c and need uplifted to aurora/beta/etc
• [21:16] KWierso so losing local changes isn't devastating
• [21:16] gps in that case, you can probably repopulate it easily enough, so |not public()| might be better
• [21:17] KWierso so | hg strip --no-backup 'roots(not public())' | ?
• [21:17] KWierso or hg strip --no-backup 'not public()' ?
• [21:20] gps the latter.
• [21:20] gps you know --no-backup is somewhat dangerous, righ?
• [21:22] KWierso yep
• [21:22] KWierso if the hg strip/hg pull combo doesn't get me back to a known-good state, I'm more than willing to delete and reclone that repository
• [21:23] KWierso less willing now if I'm using a unified repo...
• [21:24] gps generally speaking, you should *never* have to reclone
• [21:25] gps if you have extra local commits, just deal with them
• [21:25] gps not doing so ignores the realities of how distributed version control works