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

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

Checkin-neededs

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

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