Open Bug 1466381 Opened 3 years ago Updated 1 year ago
Some pushlog ranges don't work
For example: https://hg.mozilla.org/mozilla-central/rev/3b9d55ec3055 https://hg.mozilla.org/mozilla-central/rev/1f62ecdf59b6 https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=3b9d55ec3055&tochange=1f62ecdf59b6 Gives nothing :-( Also with the log IDs it doesn't work: https://hg.mozilla.org/mozilla-central/rev/3b9d55ec305565977c6d3adfe7f4eef0dd https://hg.mozilla.org/mozilla-central/rev/1f62ecdf59b6ecaa3c0fdda39bb296ec09 https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=3b9d55ec305565977c6d3adfe7f4eef0dd&tochange=1f62ecdf59b6ecaa3c0fdda39bb296ec09 Quite annoying when you're looking for regressions :-(
Summary: Some pushlog ranged don't work → Some pushlog ranges don't work
Component: Mercurial: hg.mozilla.org → Mercurial: Pushlog
From our team meeting, this is likely an issue with either the bound conditions on the revision range, or related to the revisions coming form the same push. I'll try and find the edge case shortly.
Status: NEW → ASSIGNED
When a pushlog revision-to-revision query includes a set of changes from the same push, the query returns an empty result. This is because the "where" clause on the underlying sqlite query is inclusive on on end and exclusive on the other (ie [a, b) in the corresponding mathematical notation). This is frustrating for developers who are trying to look for regressions between two commits that occurred on the same push. This commit changes the endpoints of changeset queries to be inclusive on both sides (ie [a, b]).
The problem here is that due to the way we land changes on different branches it's very common for changes that landed separately on an integration branch (inbound or autoland) to be pushed together to mozilla-central (by a sheriff doing a merge). More concretely: clicking the first two links in comment 0 will show that they both have "push id 34083", so they were pushed together to mozilla-central. Editing the URLs to point to inbound instead gives: https://hg.mozilla.org/integration/mozilla-inbound/rev/3b9d55ec3055 https://hg.mozilla.org/integration/mozilla-inbound/rev/1f62ecdf59b6 https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=3b9d55ec3055&tochange=1f62ecdf59b6 ...which shows what looks like a plausible range of changesets. This is a lousy user experience, I agree. With the benefit of hindsight I think the pushlog ought to be aware of all repositories that changesets get pushed to, so that for any given changeset you could see when it was pushed to any other repo, like "Pushed to mozilla-inbound on date X in push 123. Pushed to mozilla-central on date Y in push 456." I'm not 100% sure how you'd manage queries against the pushlog in this scenario, but it would at least be feasible.
Assignee: sheehan → nobody
Severity: critical → normal
Status: ASSIGNED → NEW
Priority: -- → P5
You need to log in before you can comment on or make changes to this bug.