1466381 - Some pushlog ranges don't work

Status: NEW

(Developer Services :: Mercurial: Pushlog, defect, P5)

Description

[Jorg K (CEST = GMT+2)]

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 :-(

Comment 1

[Connor Sheehan [:sheehan]]

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.

Comment 2

[Phabricator Automation]

Attachment: pushlog: make pushlog fromchange queries inclusive (Bug 1466381) r?gps,ted

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]).

Comment 3

[(not currently active) Ted Mielczarek]

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.

Comment 4

[Jorg K (CEST = GMT+2)]

Still not fixed after a year :-( - Very hard to document bisecting and ranges.

Working:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=d72ab884f0394d6e9ab723f03bd43c90a8&tochange=7445a65187306dfa0fc18492e7b198887a

Subset, not working:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=37e68e5fbb18940c4e8636f91dfd3071d5a6d7aa&tochange=ec8bf3fa989d552b6730b1fcad10ecad305e0769

Comment 5

[Connor Sheehan [:sheehan]]

When I took a stab at fixing this originally, I tried changing the SQL query to be inclusive on both the start and end push in a range. It was pointed out to me in review that this would change the results of over a decade of pushlog query links in bug comments, mailing list posts, etc. So making the change in such a way that it changes the pushlog query is out of the question.

The alternative proposed by Ted is to extend pushlog so that it is aware of all repos a changeset can be pushed to, essentially performing the "swap mozilla-central for integration/autoland" trick automatically. This is an interesting idea, but it isn't something I have the time to implement right now, and probably won't in the near future.

Jorg, if you have any ideas on how we can fix this bug without breaking existing links and without having to redesign the UX, I'd be happy to hear them.

Comment 6

[Jorg K (CEST = GMT+2)]

I really have no clue here. I also don't understand the problem. To me, we're querying into a continuous list of changesets, which are of course grouped into "push groups" onto mozilla-central. Why does it matter where changesets were coming from, autoland or inbound, when we're querying M-C? I don't understand that if I have a list from 1 to 200, why I can get a sublist of 50 to 150, but not 50 to 60, even if items were added to the list in chunks of 1-100 and 101-200. But obviously I don't understand how the pushlog is organised. Sorry about the ignorant reply.