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

Merges

• [20:21] KWierso trying to figure out how hard it'd be to switch my sheriffing tasks over to the Right Way(tm) from the way I'm doing them currently
• [20:22] gps like anything, there will be a learning curve
• [20:22] gps but using a unified repo was a huge time-saver for me when working with multiple repos
• [20:22] gps i recommend it for sheriffs
• [20:22] gps just don't use mq - mq doesn't work with share
• [20:23] KWierso like currently to merge inbound to mozilla-central, it's something like | cd ../mozilla-central && hg pull -u && hg pull -u && hg pull inbound | to get all of the new inbound commits, then either | hg up | or | hg merge && hg commit -m "Blah" | depending on the number of heads
• [20:23] KWierso then
• [20:23] KWierso | hg push |
• [20:23] gps i would do this in a single checkout
• [20:23] gps hg pull central
• [20:23] gps hg pull inbound
• [20:23] gps hg up central
• [20:23] gps hg merge inbound
• [20:23] gps hg commit
• [20:23] gps hg push central
• [20:24] gps (you should get in the habbit of typing `hg push -r . central`)
• [20:24] gps firefoxtree infers "-r ." when pushing to a firefox tree
• [20:25] KWierso but the actual tree would be hard to infer in that case
• [20:25] KWierso got it
• [20:25] gps what do you mean "hard to infer"?
• [20:25] KWierso er, making sure that push goes to central and not one of the others?
• [20:26] gps for those concerns, i recommend 1) always specifying the revision to push (-r <rev>) 2) always specifying the remote (not relying on default)
• [20:26] gps mercurial won't allow you to create a new head without --force
• [20:27] gps that takes away a number of obvious oops possiblities
• [20:27] gps and the firefox repos all have a hook that enforces one head per branch
• [20:28] gps even if you --force push, the server will reject it
• [20:28] gps about the worst you can do is merge the wrong commits or push a merge prematurely

Rebasing after losing a push race

• [20:35] KWierso gps: what'd be the suggested way to do the equivalent of queueing up several people's patches and easily rebasing them onto tip if I lose a push race with someone? I think that's the only thing left that I'd be wanting mq for ( qpop all of my stuff, hg pull -u to pull in newly pushed stuff, qpush my stuff back on, hg push to push my stuff)
• [20:36] gps hg pull inbound
• [20:36] gps hg rebase -d inbound
• [20:36] gps (assuming working copy is the head you are attempting to push)
• [20:37] gps fwiw, facebook wrote a mercurial extension that automatically performs a rebase on the server during push
• [20:37] gps if the push rebases cleanly (without merges), it just does it
• [20:37] KWierso facebook++
• [20:37] gps they did this because lots of people were hitting push races
• [20:37] gps we can deploy that once the mercurial feature stabilizes
• [20:38] gps facebook controls all their mercurial clients, so they can deploy experimental, api unstable versions and not have to deal with a mismatch of client versions
• [20:38] gps we don't have that luxury