Closed Bug 652858 Opened 14 years ago Closed 14 years ago

please clone tip of mozilla-aurora to mozilla-beta

Categories

(mozilla.org Graveyard :: Server Operations, task)

Product:
mozilla.org Graveyard
Component:
Server Operations
Platform:
x86
macOS
Type:
task
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: lsblakk, Assigned: nmeyerhans)

References

Details

please clone the latest mozilla-aurora tip to mozilla-beta and same for the releases/l10n/mozilla-aurora -> releases/l10n/mozilla-beta
Assignee: server-ops → nmeyerhans
All set.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
How was this done ? Normally we don't have a pushlog database (or any history in pushlog at all) after a clone request but we do for mozilla-beta, and that's causing the buildbot master for scheduling jobs to eat its face.
Re-opening while I investigate and possibly re-clone...
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Please don't reclone at this point, we're most of the way through recovery on the masters and can do without confusing them further.
OK, do you want to leave things as-is, or should we plan on pruning pushlog history at a later time?
I think we can leave things as-is now and call this fixed.
Status: REOPENED → RESOLVED
Closed: 14 years ago → 14 years ago
Resolution: --- → FIXED
Maybe not. TBPL gets 40MB of data back from the request http://hg.mozilla.org/releases/mozilla-beta/json-pushes?full=1&maxhours=24 even though there are only two small changes today. Removing the full=1 doesn't help. I think it must be looking at every change in the very large initial push. Ted, what are our options for trimming the pushlog db here ? Will the problem go away as we push more changes into beta ?
pushlog is an sqlite database, so the mechanics of trimming it should be straightforward. I'm not sure how that will play with the rest of the repository, though.
The pushlog is not connected to the rest of the repo, it's a Mozilla extension. You should be able to delete all but one changeset from the initial push and make this problem go away. Maybe something like: DELETE FROM changesets WHERE pushid=1 AND rev < (SELECT MAX(rev) FROM changesets WHERE pushid=1)
Nick, do you want me to go ahead and run the SQL that Ted posted? DELETE FROM changesets WHERE pushid=1 AND rev < (SELECT MAX(rev) FROM changesets WHERE pushid=1)
Product: mozilla.org → mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.