WebRTC has just landed - however, the import changesets included many large files that were removed by later changesets in the push, but still get added to history since they weren't qfolded. ie: (2012-06-20 14:04:36) glandium: so, if i pull from inbound, my .hg grows by about 250MB (2012-06-20 14:05:24) glandium: if i then take the diff between c5b6ac34b293 and the tip of inbound, and then apply it on another clone, .hg grows by... 14MB We therefore would like to strip inbound rev 3d3c19f6c09f and newer, which is the very last push: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?changeset=1e066a4b6176 Ted says the pushlog hook will likely needed disabling temporarily whilst we strip. We will also need to fixup the pushlog db to remove the now non-existent 1e066a4b6176 push. Not sure if the builders need anything doing to them as well. Once those changesets are stripped & something else landed on inbound, the single-head-per-tree hook (we must remember to re-enable it!) should protect us from people pushing those changesets again (if they've pulled in the hour since it landed on inbound). We could even add a temporary message to the single head hook saying "please strip using: hg strip -r zzzzzz (see bug YYYYY)" etc
(Inbound has been closed pending the strip.)
Assignee: server-ops → server-ops-devservices
Component: Server Operations → Server Operations: Developer Services
QA Contact: phong → shyam
(In reply to Ed Morley [:edmorley] from comment #0) > WebRTC has just landed - however, the import changesets included many large > files that were removed by later changesets in the push, but still get added > to history since they weren't qfolded. > > ie: > (2012-06-20 14:04:36) glandium: so, if i pull from inbound, my .hg grows by > about 250MB > (2012-06-20 14:05:24) glandium: if i then take the diff between c5b6ac34b293 > and the tip of inbound, and then apply it on another clone, .hg grows by... > 14MB <glandium> ehsan: let me check if I have everything, though. i could be missing binary files <glandium> ehsan: it's only a partial explanation. instead of 14MB, it's 56MB <glandium> still far from 256MB
communicated via irc but for everyone else, I'm backing things up inbound first, I don't like what I'm reading about the riskiness of the strip command :)
added mq = to [extensions] in hgrc to allow hg strip. This will get removed in the next puppet run. [firstname.lastname@example.org mozilla-inbound]# hg strip 3d3c19f6c09f saved backup bundle to /repo/hg/mozilla/integration/mozilla-inbound/.hg/strip-backup/3d3c19f6c09f-backup.hg the pushlog entry (only pasting the one that counts): sqlite> select * from changesets where pushid = '10884'; 10884|97127|3d3c19f6c09f3f9e22f9acf5301a64e585c9fbce sqlite> delete from changesets where rev = '97127'; I'm not sure if the gap in sequence for changeset revs will cause a problem in pushlog or not. If so there's a lot more work to be done here. If not, we should be all set.
Thank you for this! Unfortunately the pushlog is blank at the moment: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml
my bad, thought we had only removed the offending change, not the whole commit. Fixed in pushlog: sqlite> delete from pushlog where id='10884'; sqlite> delete from changesets where pushid='10884'; all fixed up here.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
Thank you for doing this! :-) I have posted: https://groups.google.com/d/topic/mozilla.dev.platform/WuNBfCuScKs/discussion == We unfortunately had to strip WebRTC changesets from mozilla-inbound today (see bug 766533). If you pulled mozilla-inbound between 0455 and 0720 PDT today, then you will need to: 1) Pop any applied patches/save the state of your working directory/qimport anything you've qfinished. 2) hg strip 3d3c19f6c09fhg (Optional: --no-backup) 3) hg up -C Note: Strip is part of mq. To enabled mq, add the following to your hgrc: [extensions] mq = The single-head-per-push hook will protect mozilla-inbound from anyone inadvertently re-pushing the stripped changesets. ==
Sorry, that should read: 2) hg strip 3d3c19f6c09f
Component: Server Operations: Developer Services → General
Product: mozilla.org → Developer Services
You need to log in before you can comment on or make changes to this bug.