debian: fix lintian warning about debhelper
It seems this is correct but does it work on older distros? I ran the
docker-jessie rule and didn't get any warnings.
builddeb: remove chmod as lintian tells us
It turns out we just need debian/rules to be executable, so we do just that.
builddeb: use codename in version
Apparently, this is needed to allow ppas to be built for multiple distros.
rebase: restrict rebase destination to the pulled set (
issue5214)
Before this patch, `hg pull --rebase` would be a strict sequence of `hg pull`
followed by `hg rebase` if anything was pulled.
Now that rebase pick his default destination the same way than merge, than
`hg rebase` step would abort in the case the repo already had multiple anonymous
heads (because of the ambiguity). (changed in
fac3a24be50e)
The intend of the user with `hg pull --rebase` is clearly to rebase on pulled
content. This used to be (mostly) enforced by the former default destination for
rebase, "tipmost changeset of the branch" as the tipmost would likely a
changeset that just got pulled. But this intended was no longer enforced with
the new defaul destination (unified with merge).
This changeset makes use of the '_destspace' mechanism introduced in the previous
changeset to enforce this.
This partially fixes
issue5214 as no change at all have been made to the new
handling of the case with bookmark (unified with merge).
destutil: add the ability to specify a search space for rebase destination
In the 'hg pull --rebase', we don't want to pick a rebase destination unrelated
to the pull, we lay down basic infrastructure to allow such restriction on
stable (before 3.8 release) in this case. See issue 5214 for details.
Actual usage and test will be in the next patch.
sslutil: restore old behavior not requiring a hostname argument (
issue5210)
This effectively backs out changeset
1fde84d42f9c.
The http library behind ui.http2=true isn't specifying the hostname.
It is the day before the expected 3.8 release and we don't want to ship
a regression.
I'll try to restore this requirement in the 3.9 release cycle as part
of planned improvements to Mercurial's SSL/TLS interactions.
tests: test a variety of cache invariants
We've historically had a problem maintaining the expected invariants
on our caches, especially when introducing new caches. This tests
documents the invariants and exercises them across most of our
existing cache files.
repoview: ignore unwritable hidden cache
The atomictemp.close() file attempts to do a rename, which can fail.
Moving the close inside the exception handler fixes it.
This doesn't fit well with the with: pattern, as it's the finalizer
that's failing.
tags: silence hgtagsfnodes reading failures
tryread() doesn't handle "is a directory" errors and presumably
others. We might not want to globally swallow such tryread errors, so
we replace with our own try/except handling.
An upcoming test will use directories as a portable stand-in for
various bizarre circumstances that cache read/write code should be
robust to.