setup: treat error output and non-zero return code differently
Choking on Mercurial's stderr mean armless warning can derails the whole install
process. We do like to be able to issue warning to people so we stop considering
any stderr is a fatal mistake.
This allow us to actually boostrap a version of Mercurial without loosing to
many sanity point. For example in case where evolve is not loaded, something
that happens when the recorded version is malformatted. Creating a wonderful
ouroboros.
setup: make the version computation process more resistant
The tag fetching might return and empty stringĀ¹, from there everything derails
quickly. As setup tools becomes more picky about version format we make the
whole seems a bit more robust.
The resulting version will be obviously weird, but at least it will actually
install itself.
[1] This is a problem we will address in the next changesets.
bundlerepo: enforce the requirements declared by the underlying repository
Previously, `hg log -r 'bundle()' -R bundle.hg` was failing for me when run from
source, complaining about an unknown parent, when the system installed `hg`
didn't. Some debugging showed the index was 0 length. It turned out that I
didn't have the C extensions compiled, which a simple `hg log -r .` was able to
indicate. The problem being that the RequirementError got handled by RepoError,
which uses an empty directory as a fallback to process the bundle.
scmutil: make checknewlabel() allow "_" in otherwise numeric names (
issue6737)
dirstate: enforce holding the lock while doing any changes
This seems like a sensible sanity check. This already caught the issue in
largefile. This will catch more issue when we start using similar context
manager for operation other than the parent changes.