Sheriffing/How To/Unified Repos

From MozillaWiki
< Sheriffing
Revision as of 00:56, 1 January 2015 by KWierso (talk | contribs) (Document non-tip merges)
Jump to navigation Jump to search

Unified Repos

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

Setting up the repo

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

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
Retrieved from "https://wiki.allizom.org/index.php?title=Sheriffing/How_To/Unified_Repos&oldid=1044449"