For regression ranges, please be careful to link to the right pushlog

[L. David Baron]

When using pushloghtml links to list the changesets in a regression
range, you have to link to the pushloghtml for the correct
repository.

This means that if you're testing builds generated from b2g-inbound
and you find a before build (last build without the regression) and
an after build (first build with the regression), you can generate a
link like:
https://hg.mozilla.org/integration/b2g-inbound/pushloghtml?fromchange=66aa08862214&tochange=106e5393967b

However, while the same link for mozilla-central gives results:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=66aa08862214&tochange=106e5393967b
these results give a different (and incorrect) list of changesets
that might have caused the regression.

If you know the changesets that your builds were generated from, but
don't know which repository to use, you can generate a regression
range using hg:
hg log -r 'ancestors(106e5393967b) - ancestors(66aa08862214)'


A little more detail, in case you're interested:

Why is the second link wrong? It's wrong because the changesets
reached mozilla-central in a different order than they reached
mozilla-inbound. This happens because we land changesets in
multiple repositories and then merge the repositories (this creates
a graph of revisions, in which most changesets have one parent but
merges have two parents).

A reliable sign that the second pushlog link is wrong is that either
one of the fromchange and tochange (in this case, both) were not the
tip of their respective pushes:
https://hg.mozilla.org/mozilla-central/pushloghtml?changeset=66aa08862214
https://hg.mozilla.org/mozilla-central/pushloghtml?changeset=106e5393967b

-David

--
𝄞 L. David Baron http://dbaron.org/ 𝄂
𝄢 Mozilla https://www.mozilla.org/ 𝄂
Before I built a wall I'd ask to know
What I was walling in or walling out,
And to whom I was like to give offense.
- Robert Frost, Mending Wall (1914)

[Karl Tomlinson]

% hg log -r 44ba69cacd7e..01a67765dbc7 content/media
% hg diff -r 44ba69cacd7e -r 01a67765dbc7 | lsdiff
a/content/canvas/test/webgl/skipped_tests_linux_mesa.txt
a/content/media/AudioStream.cpp
a/content/media/MediaStreamGraph.cpp
a/content/media/encoder/fmp4_muxer/ISOControl.cpp
a/content/media/encoder/fmp4_muxer/ISOControl.h
a/content/media/encoder/fmp4_muxer/ISOMediaBoxes.cpp
a/content/media/encoder/fmp4_muxer/ISOMediaBoxes.h
a/content/media/encoder/fmp4_muxer/ISOMediaWriter.cpp
a/content/media/webaudio/AudioContext.cpp
a/layout/base/nsDocumentViewer.cpp
a/layout/base/nsLayoutUtils.cpp
a/testing/mochitest/b2g.json
a/testing/xpcshell/runxpcshelltests.py
% hg log -vr 01a67765dbc7
changeset: 166582:01a67765dbc7
parent: 166570:44ba69cacd7e
parent: 166581:db60f1d540c4
user: Carsten "Tomcat" Book <cb...@mozilla.com>
date: Mon Feb 03 12:59:32 2014 +0100
description:
merge mozilla-inbound to mozilla-central

[Gregory Szorc]

I suggest everyone to the time to learn how to use revisions sets [1]
along with the "not merge()" selector:

$ hg log -r 'f66e3ccb0c41::a10d0ba50f64 and not merge()'

Read [2] for info about my Mercurial extension that can add
pushlog-based revision sets and templates. You can accomplish the same
things dbaron pointed out in the original post without sludging through
the web interface. e.g. to find changesets that were built by automation
(they were a pushed head at one point) inside a revision range:

$ hg log -r '66aa08862214::106e5393967b & pushhead("b2g-inbound")'
--template '{firstpushtbpl}\n'
https://tbpl.mozilla.org/?tree=B2Ginbound&rev=66aa08862214
https://tbpl.mozilla.org/?tree=B2Ginbound&rev=322d13b6e306
https://tbpl.mozilla.org/?tree=B2Ginbound&rev=e60fd5e15e99
https://tbpl.mozilla.org/?tree=Mozilla-Central&rev=22650589a724
https://tbpl.mozilla.org/?tree=B2Ginbound&rev=6428b50e4dc0
https://tbpl.mozilla.org/?tree=B2Ginbound&rev=5160d02b643c
https://tbpl.mozilla.org/?tree=B2Ginbound&rev=9cff5a75c1be
https://tbpl.mozilla.org/?tree=B2Ginbound&rev=9ce9bdf1ffe7
https://tbpl.mozilla.org/?tree=B2Ginbound&rev=62cef6077cb4
https://tbpl.mozilla.org/?tree=B2Ginbound&rev=106e5393967b

(If you omit the argument to pushhead() you'll get results for all
trees, which is a more comprehensive regression range than what you
would get querying a single repo's pushlog via hgweb.)

Install the aforementioned extension and run `hg help mozext` for a
detailed list of all the query and reporting options. Report bugs and
request new features at [3].

[1] http://www.selenic.com/hg/help/revsets
[2]
http://gregoryszorc.com/blog/2013/11/08/using-mercurial-to-query-mozilla-metadata/
[3]
https://bugzilla.mozilla.org/enter_bug.cgi?product=Other%20Applications&component=mozext

[L. David Baron]

On Wednesday 2014-03-12 11:29 -0700, Gregory Szorc wrote:
> I suggest everyone to the time to learn how to use revisions sets
> [1] along with the "not merge()" selector:
>
> $ hg log -r 'f66e3ccb0c41::a10d0ba50f64 and not merge()'

That's not going to work if your goal is to find a regression range.

"hg log -r 'fromchange::tochange'" shows changesets that are
descendants of fromchange *and* ancestors of tochange. This means
that if something was merged in along the path or paths between
these changesets, you'll see *only* the merge commit in that log,
and not the changesets that were merged in. In other words, you'd
see only a changeset with summary like "Merge mozilla-central to
fx-team".

If you remove merges from that set, then the log won't show you any
sign at all of the things that were merged in -- neither the changes
along the merged-in path, nor the merge commits themselves.


"hg log -r '(ancestors(tochange) - ancestors(fromchange)) and not
merge()'" may well be a useful command, though.

But in general, I think it makes much more sense to look for
regression ranges in 'ancestors(tochange) - ancestors(fromchange)'
than in 'ancestors(tochange) and descendants(fromchange)', since the
latter requires that you consider merges as significant rather than
showing you the merged-in changesets as part of the list.
Unfortunately :: in hg is syntactic sugar for the latter rather than
the former.