We're about to deploy this to release automation. We might as well have
normal people start using it as well. We could perhaps even have the
extension print out information on how to resume interrupted downloads
someday, so it will pay to have this enabled so they can utilize that
feature some day in the future.
DONTBUILD (NPOTB)
--HG--
extra : commitid : CVW0xQNKjt3
extra : rebase_source : 8c5f609b036ac081c1af5f7428bb8d4a4c2ed476
extra : histedit_source : adb57e6fbb5f50af619fb98e1fbb17c815aca76e
We dropped support for Mercurial 3.0 in version-control-tools. Bump
minimum versions in extensions to reflect this.
We highly recommend people run a modern Mercurial. Bump the minimum
non-legacy version to reflect that.
--HG--
extra : commitid : 8YtjoVnYauL
extra : rebase_source : 949c27a376226bbd32430047176012b51e891255
extra : histedit_source : aff04954269ed777c9b26ec3f1fda6526b1ae317
CLOSED TREE
Backed out changeset 12ce98475c6e (bug 1119980)
Backed out changeset bdb8d05f8870 (bug 1119980)
Backed out changeset a68a18840492 (bug 1119980)
Currently we only mark the version-control-tools repo as needing updating, if
we did not pass a path param to prompt_external_extension(). This is because if
no path is passed, the extension is used from the version-control-tools repo,
and so if _no_ path is passed, it's presumed the extension is external to the
repo. However this is not always the case - eg if we need to specify a specific
file for an extension (vs the entire directory), we have to do so be passing in
the path. We hit this case for reviewboard.
With this change, we always mark the version-control-tools repo as needing an
update, no matter where the extension was located.
mqext was moved into the version-control-tools repo some time ago, but mach
mercurial-setup was still pointing at the old repo location, which is no longer
being updated.
This is needed for compatibility with an upcoming release of
MozillaBuild, which distributes Mercurial as a Python package, not as a
standalone Windows program. As a result, it introduces "hg" into $PATH,
which "which" will happily prefer as the "hg" binary. This upsets
subprocess. So, we explicitly prefer "hg.exe" over "hg".
We could accomplish the same thing by calling which.whichall() and
sorting results. But this is more code and IMO not worth the effort to
implement.
--HG--
extra : rebase_source : 750ba02c02fd4a9fab42ccf128eab4f5e7741564
extra : amend_source : 8fb84c0ed5cd14dd27ad6cd7b78fb2ac1ffc87a2