Confirmed users
396
edits
Sheriffing/How To/Unified Repos: Difference between revisions
Sheriffing/How To/Unified Repos (view source)
Revision as of 05:26, 31 December 2014
, 31 December 2014How to recover a messed up repo
(First change) |
(How to recover a messed up repo) |
||
| Line 49: | Line 49: | ||
* [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 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 | * [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 | |||