cmdutil: split functions of log-like commands to new module (API) cmdutil.py is painfully big and makes Emacs slow. Let's split log-related functions. % wc -l mercurial/cmdutil.py 4027 mercurial/cmdutil.py % wc -l mercurial/cmdutil.py mercurial/logcmdutil.py 3141 mercurial/cmdutil.py 933 mercurial/logcmdutil.py 4074 total

httppeer: remove support for connecting to <0.9.1 servers (BC) Previously, HTTP wire protocol clients would attempt a "capabilities" wire protocol command. If that failed, they would fall back to issuing a "between" command. The "capabilities" command was added in Mercurial 0.9.1 (released July 2006). The "between" command has been present for as long as the wire protocol has existed. So if the "between" command failed, it was safe to assume that the remote could not speak any version of the Mercurial wire protocol. The "between" fallback was added in 395a84f78736 in 2011. Before that changeset, Mercurial would *always* issue the "between" command and would issue "capabilities" if capabilities were requested. At that time, many connections would issue "capabilities" eventually, so it was decided to issue "capabilities" by default and fall back to "between" if that failed. This saved a round trip when connecting to modern servers while still preserving compatibility with legacy servers. Fast forward ~7 years. Mercurial servers supporting "capabilities" have been around for over a decade. If modern clients are connecting to <0.9.1 servers, they are getting a bad experience. They may even be getting bad data (an old server is vulnerable to numerous security issues and could have been p0wned, leading to a Mercurial repository serving backdoors or other badness). In addition, the fallback can harm experience for modern servers. If a client experiences an intermittent HTTP request failure (due to bad network, etc) and falls back to a "between" that works, it would assume an empty capability set and would attempt to communicate with the repository using a very ancient wire protocol. Auditing HTTP logs for hg.mozilla.org, I did find a handful of requests for the null range of the "between" command. However, requests can be days apart. And when I do see requests, they come in batches. Those batches seem to correlate to spikes of HTTP 500 or other server/network events. So I think these requests are fallbacks from failed "capabilities" requests and not from old clients. If you need even more evidence to discontinue support, apparently we have no test coverage for communicating with servers not supporting "capabilities." I know this because all tests pass with the "between" fallback removed. Finally, server-side support for <0.9.1 pushing (the "addchangegroup" wire protocol command along with locking-related commands) was dropped from the HTTP client in fda0867cfe03 in 2017 and the SSH client in 9f6e0e7ef828 in 2015. I think this all adds up to enough justification for removing client support for communicating with servers not supporting "capabilities." So this commit removes that fallback. Differential Revision: https://phab.mercurial-scm.org/D2001

internals: document when "hello" and "capabilities" commands were added Both were introduced in 0.9.1. "hello" made its entrance in b17eebc911ae, 144280f1578f, and a1cfe679192c to support SSH. "capabilities" was added in c660691fb45d to support HTTP. Differential Revision: https://phab.mercurial-scm.org/D2000

tests: make doctest py3-compatible again A parsed tree is replaced with parse(expr) because it sucks to add b'' to every string literal.

lfs: emit a status message to indicate how many blobs were uploaded Previously, there was a progress bar indicating the byte count, but then it disappeared once the transfer was done. Having that value stay on the screen seems useful. Downloads are done one at a time, so hold off on that until they can be coalesced, to avoid a series of lines being printed. (I don't have any great ideas on how to do that. It would be a shame to have to wrap a bunch of read commands to be able to do this.) I'm not sure if the 'lfs:' prefix is the right thing to do here. The others in the test are verbose/debug messages, so in the normal case, this is the only line that's prefixed.

lfs: drop an unused function parameter

discovery: don't reimplement all() Differential Revision: https://phab.mercurial-scm.org/D1993

contrib: fix dirstatenonnormalcheck to work in Python 3 This is a redo of D1963 that has the added benefit of not breaking Python 2. Oops. # skip-blame because this is bytes prefixes and a s/iteritems/items/ Differential Revision: https://phab.mercurial-scm.org/D1970

python3: whitelist another 24 passing tests Differential Revision: https://phab.mercurial-scm.org/D1911

mdiff: use slice instead of index on bytestr when checking single bytes This is portable to Python 3. Differential Revision: https://phab.mercurial-scm.org/D1992

obsutil: work around filter() being a generator in Python 3 Differential Revision: https://phab.mercurial-scm.org/D1910

cmdutil: add a kludge to make bytes repr() the same on 2 and 3 This fixes the output formatting problems I see in debugobsolete. I still am seeing some effectflag differences, which we'll need to tackle separately. I'm not in love with this approach. There might be something better we could do, and I'd love it if someone else wanted to take a run at this. Differential Revision: https://phab.mercurial-scm.org/D1909

wireprotoserver: make name part of protocol interface This is a required part of the interface. Abstract properties must be defined at type creation time. So we make name a @property. Differential Revision: https://phab.mercurial-scm.org/D1991

wireprotoserver: make abstractserverproto a proper abstract base class Plug in the abc module so we can have run-time validation of type conformance. Differential Revision: https://phab.mercurial-scm.org/D1990

wireprotoserver: make response handling attributes private The send* methods are specific to sshserver and aren't part of the common protocol interface. So rename them accordingly. The handlers dict is also specific to sshserver and is related to these methods. So give it the same treatment. Differential Revision: https://phab.mercurial-scm.org/D1989

wireprotoserver: make some instance attributes private sshserver attempts to conform to a well-defined interface. The instance attributes changed as part of this commit don't appear to be part of that interface. So prefix them with _ to mark them as private. Differential Revision: https://phab.mercurial-scm.org/D1988

wireprotoserver: remove sshserver.getarg() AFAICT the last consumer of this helper method was removed by d054cc5c7737 in 2010. Differential Revision: https://phab.mercurial-scm.org/D1987

wireprotoserver: remove lock references AFAICT sshserver.lock is unused. The last caller of it disappeared in 9f6e0e7ef828 ~18 months ago as part of removing code to support ancient wire protocol commands. Let's remove some dead code. Differential Revision: https://phab.mercurial-scm.org/D1986

wireprotoserver: remove support for do_<command> handlers (API) Old versions of wire protocol handlers relied on methods named do_<command> to handle wire protocol commands. The last definition of these methods on sshserver was removed by 9f6e0e7ef828 ~2 years ago. I think it's time to not support this mechanism for defining command handlers. .. api:: sshserver no longers looks for wire protocol command handlers in methods named do_<command>. Use @wireproto.wireprotocommand to declare wire protocol command handler functions. Differential Revision: https://phab.mercurial-scm.org/D1985

wireprotoserver: make attributes private These aren't part of the protocol interface. So they should be _ prefixed. Differential Revision: https://phab.mercurial-scm.org/D1984

wireprotoserver: remove unused response attribute I think the last use of this attribute was removed by 2f8adc60e013 in 2010. Differential Revision: https://phab.mercurial-scm.org/D1983

wireprotoserver: rename p to proto To aid readability. And to make it easier to search the code base for protocol instances. Differential Revision: https://phab.mercurial-scm.org/D1982

wireprotoserver: add some blank lines between methods Let's make this file slightly easier to read. Differential Revision: https://phab.mercurial-scm.org/D1981

tests: start a set of unit tests for mdiff.py, starting with splitnewlines I want to optimize splitnewlines, so writing tests seems prudent. Differential Revision: https://phab.mercurial-scm.org/D1972 # no-check-commit because of test_ funciton

perf: add a perfunidiff command for benchmarking unified diff speed Differential Revision: https://phab.mercurial-scm.org/D1971

wireprotoserver: move abstractserverproto class from wireproto Let's have the interface live next to things that define it. Differential Revision: https://phab.mercurial-scm.org/D1969

wireprotoserver: move sshserver into module (API) Let's welcome the SSH protocol handler to our new central home for protocol handlers. .. api:: Content from mercurial.sshserver has been moved into mercurial.wireprotoserver. Differential Revision: https://phab.mercurial-scm.org/D1968 # no-check-commit because we're moving a foo_bar function

wireprotoserver: don't import symbol from hgweb.common Importing hgweb.common requires importing hgweb. hgweb/__init__.py contains a bit of code and does imports of large parts of the hgweb.* module tree. All we need is a constant defining the integer status code for HTTP OK. So just redefine HTTP_OK in wireprotoserver.py and avoid the excessive imports. Differential Revision: https://phab.mercurial-scm.org/D1967

wireprotoserver: rename call to callhttp In the context of multiple handlers, call() is ambiguous. Differential Revision: https://phab.mercurial-scm.org/D1966

wireprotoserver: rename hgweb.protocol to wireprotoserver (API) The HTTP wire protocol server / response handler is currently defined in the hgweb sub-package. That only kind of makes sense. hgweb does contain most of the HTTP server code. However, hgweb is more tailored for providing HTTP server and WSGI scaffolding and serving hgweb requests. The wire protocol is kind of its own beast. In addition, the code for HTTP and SSH wire protocol handling is actually pretty small and it needs to stay in sync to ensure parity between the transport implementations. We rename mercurial/hgweb/protocol.py to mercurial/wireprotoserver.py. The new module will eventually become the home of the SSH handler as well. .. api:: Content from mercurial.hgweb.protocol has been moved to mercurial.wireprotoserver. Differential Revision: https://phab.mercurial-scm.org/D1965

testrunner: fix updating of .testtimes file We attempt to write the 5 most recent test timings to a file called .testtimes, but we read previous results from a file called .testtimes- (including the hyphen), so we ended up no more than a single time per test. Differential Revision: https://phab.mercurial-scm.org/D1961

testrunner: make reading of test times work with #testcases Due to a bug that will be fixed in the next patch, we never actually read back .testcases, so we didn't notice that it could not be parsed successfully when there are #testcases tests. The parsing failed on lines like "test-amend-subrepo.t (case obsstore-off) 32.420" because we used a simple string.split() call and expected all parts but the first to be floating point numbers (and "(case" isn't, for example). Fix by using a regex instead. Differential Revision: https://phab.mercurial-scm.org/D1960

tests: allow [Errno] in output I'm not sure why, but my system is printing "[Errno -5]" before the "No address associated with hostname" message. I suspect a modern version of Python improved errno tracking or something. Add an "[Errno ...]" pattern as optional output to make the test pass. Differential Revision: https://phab.mercurial-scm.org/D1958

mdiff: remove rewindhunk by yielding a bool first to indicate data Differential Revision: https://phab.mercurial-scm.org/D1942

mdiff: explicitly compute places for the newline marker Differential Revision: https://phab.mercurial-scm.org/D1941

patch: avoid repeated binary checks if all files in a patch are text Differential Revision: https://phab.mercurial-scm.org/D1940

setdiscovery: don't call "heads" wire command when heads specified Our custom server has too many heads to announce (one per code review, plus a public head), but it still lets the user request one of them by doing hg pull -r <some expression> After the client has resolved the expression to a set of nodeids by calling the "lookup" wire command, it will start the discovery phase. Before this patch, that doesn't take the requested heads into account and unconditionally calls the server's "heads" command to find all its heads. One consequence of that the "all remote heads known locally" case triggers if the client already had the public head and the user will see a "no changes found" message that's unrelated to the head they requested. That message confused me for a while. More imporantly, it also means that pullop.cgresult incorrectly (given our arguably misbehaving server) gets set to 0 (no changesets added), which confused some of our extensions. This patch makes it so the client skips the "heads" command if the user requested specific revisions. Since the "heads" command is normally batched with the first "known" command and calculating the list of heads is probably cheap, I don't expect much improvement in speed from this. Differential Revision: https://phab.mercurial-scm.org/D1962

testrunner: on error, color the "(case xxx)" part the same as filename When using #testcases, the lines that read something like ERROR: test-split.t (case obsstore-off) output changed get colored red and the filename gets highlighted with a brighter red. This makes it harder to notice the "case obsstore-off" part, but it does seem important, so let's highlight it. Differential Revision: https://phab.mercurial-scm.org/D1959

python3: whitelist an additional 23 passing tests Differential Revision: https://phab.mercurial-scm.org/D1908

tests: fix a missed b prefix in a test extension in test-strip.t # skip-blame just a bytes prefix Differential Revision: https://phab.mercurial-scm.org/D1907

revlog: correct type in check to verify rawtext is immutable This fixes far more failures than I feel like it has any right to, so there's clearly some subtle interaction between self._cache and other parts of this code. :( Differential Revision: https://phab.mercurial-scm.org/D1906

mq: use bytes() instead of str() to encode statusentries for writing Differential Revision: https://phab.mercurial-scm.org/D1903

mq: open status file et al in bytes mode Differential Revision: https://phab.mercurial-scm.org/D1902

mq: fix up statusentry to be both repr()-able and bytes()-able Differential Revision: https://phab.mercurial-scm.org/D1901

python3: whitelist another 7 passing tests Differential Revision: https://phab.mercurial-scm.org/D1900

localrepo: pass transaction kwargs as strings, not bytes Differential Revision: https://phab.mercurial-scm.org/D1899

localrepo: consistently use native str when __dict__ is involved Differential Revision: https://phab.mercurial-scm.org/D1898

smartset: use native string when peeking in __dict__ # skip-blame just an r prefix on a string literal Differential Revision: https://phab.mercurial-scm.org/D1897

obsolete: use native string when peeking in __dict__ # skip-blame just an r prefix on a few string literals Differential Revision: https://phab.mercurial-scm.org/D1896

lsprof: use native string when peeking in __dict__ # skip-blame just an r prefix on a string literal Differential Revision: https://phab.mercurial-scm.org/D1895

dirstate: use native strings when peeking in __dict__ # skip-blame because we're just adding a prefix on a string prefix Differential Revision: https://phab.mercurial-scm.org/D1894

context: use native string when peeking in __dict__ # skip-blame because we're just adding a prefix on a string constant Differential Revision: https://phab.mercurial-scm.org/D1893

bundlerepo: use native str when peeking in __dict__ # skip-blame since it's just a string constant prefix Differential Revision: https://phab.mercurial-scm.org/D1892

transaction: fix hg version check when loading journal Differential Revision: https://phab.mercurial-scm.org/D1891

branchmap: make error messages consistent between Python 2 and 3 Differential Revision: https://phab.mercurial-scm.org/D1890

tests: bytestring-ify all the adhoc extensions in test-strip.t # skip-blame because we're just adding b'' Differential Revision: https://phab.mercurial-scm.org/D1889

filemerge: fix regular expression pattern to be bytes # skip-blame just a bytes prefix Differential Revision: https://phab.mercurial-scm.org/D1888

tags: explicitly grab list of dict keys Differential Revision: https://phab.mercurial-scm.org/D1887

commands: replace map() with list comprehension This will work identically on Python 2 and 3. Differential Revision: https://phab.mercurial-scm.org/D1886

commands: rewrite legacy ternary operator hack using modern syntax Differential Revision: https://phab.mercurial-scm.org/D1885

strip: use %d for known-int string interpolation Differential Revision: https://phab.mercurial-scm.org/D1884

strip: use in-place revset formatspec instead of %-formatting ourselves Caught by Yuya during review of D1884. Differential Revision: https://phab.mercurial-scm.org/D1905

tests: get run-tests to reliably hand shellquote a string and not a bytes Differential Revision: https://phab.mercurial-scm.org/D1883

revsetlang: fix a doctest example on Python 3 # skip-blame because it's just some bytes prefixes Differential Revision: https://phab.mercurial-scm.org/D1964

merge with stable

Added signature for changeset 7de7bd407251

Added tag 4.5.3 for changeset 7de7bd407251

server: ensure the incoming request falls under the prefix value Prior to this, the first test asserted in wsgiref.validate.check_environ() saying PATH didn't start with '/', but the second test served up the repo. The assertion was just added in this cycle (though the value of PATH is still wrong without the assertion). Allowing access to the repo at any URL outside of the prefix is a long standing bug. This also affected hgwebdir, at least when used via --subrepo. Paths are not being canonicalized, so accesses to things like 'foo/../bar' will get tossed out here, unless the prefix also matches.

rebase: on abort, don't strip commits that didn't need rebased (issue5822) I clearly missed adding this condition in 78496ac30025 (rebase: allow rebase even if some revisions need no rebase (BC) (issue5422), 2017-05-11). Perhaps I should have opted for the "revdone" solution I mentioned there... Differential Revision: https://phab.mercurial-scm.org/D2879

rebase: avoid defining two lists with the same contents In abort(), there's "dstates" and "rebased" that are identical, which they seem to have been since 0806823370d8 (rebase: properly calculate descendant set when aborting (issue3332), 2012-03-22). Let's de-duplicate. I don't know what "dstates" means, but "rebased" makes sense (it's the list of rebased revisions), so let's pick that. Differential Revision: https://phab.mercurial-scm.org/D2878

tests: demonstrate aborted rebase strips commits that didn't need rebasing I haven't verified, but this has probably been broken ever since I added the feature in 78496ac30025 (rebase: allow rebase even if some revisions need no rebase (BC) (issue5422), 2017-05-11). Differential Revision: https://phab.mercurial-scm.org/D2877

hgweb: garbage collect on every request There appears to be a cycle in localrepository or hgweb that is preventing repositories from being garbage collected when hgwebdir dispatches to hgweb. Every request creates a new repository instance and then leaks that object and other referenced objects. A periodic GC to find cycles will eventually collect the old repositories. But these don't run reliably and rapid requests to hgwebdir can result in rapidly increasing memory consumption. With the Firefox repository, repeated requests to raw-file URLs leak ~100 MB per hgwebdir request (most of this appears to be cached manifest data structures). WSGI processes quickly grow to >1 GB RSS. Breaking the cycles in localrepository is going to be a bit of work. Because we know that hgwebdir leaks localrepository instances, let's put a band aid on the problem in the form of an explicit gc.collect() on every hgwebdir request. As the inline comment states, ideally we'd do this in a finally block for the current request iff it dispatches to hgweb. But _runwsgi() returns an explicit value. We need the finally to run after generator exhaustion. So we'd need to refactor _runwsgi() to "yield" instead of "return." That's too much change for a patch to stable. So we implement this hack one function above and run it on every request. The performance impact of this change should be minimal. Any impact should be offset by benefits from not having hgwebdir processes leak memory.

amend: abort if unresolved merge conflicts found (issue5805) It was checked by repo.commit() before e8a7c1a0565a "cmdutil: remove the redundant commit during amend."

Added signature for changeset 8bba684efde7

Added tag 4.5.2 for changeset 8bba684efde7

merge with security patches

hgweb: always perform permissions checks on protocol commands (BC) (SEC) Previously, the HTTP request handling code would only perform permissions checking on a wire protocol command if that wire protocol command defined its permissions / operation type. This meant that commands (possibly provided by extensions) not defining their operation type would bypass permissions check. This could lead to exfiltration of data from servers and mutating repositories that were supposed to be read-only. This security issue has been present since the permissions table was introduced by d3147b4e3e8a in 2008. This commit changes the behavior of the HTTP server to always perform permissions checking for protocol requests. If an explicit permission for a wire protocol command is not defined, the server assumes the command can be used for writing and governs access accordingly. .. bc:: Wire protocol commands not defining their operation type in ``wireproto.PERMISSIONS`` are now assumed to be used for "push" operations and access control to run those commands is now enforced accordingly.

wireproto: check permissions when executing "batch" command (BC) (SEC) For as long as the "batch" command has existed (introduced by bd88561afb4b and first released as part of Mercurial 1.9), that command (like most wire commands introduced after 2008) lacked an entry in the hgweb permissions table. And since we don't verify permissions if an entry is missing from the permissions table, this meant that executing a command via "batch" would bypass all permissions checks. The security implications are significant: a Mercurial HTTP server would allow writes via "batch" wire protocol commands as long as the HTTP request were processed by Mercurial and the process running the Mercurial HTTP server had write access to the repository. The Mercurial defaults of servers being read-only and the various web.* config options to define access control were bypassed. In addition, "batch" could be used to exfiltrate data from servers that were configured to not allow read access. Both forms of permissions bypass could be mitigated to some extent by using HTTP authentication. This would prevent HTTP requests from hitting Mercurial's server logic. However, any authenticated request would still be able to bypass permissions checks via "batch" commands. The easiest exploit was to send "pushkey" commands via "batch" and modify the state of bookmarks, phases, and obsolescence markers. However, I suspect a well-crafted HTTP request could trick the server into running the "unbundle" wire protocol command, effectively performing a full `hg push` to create new changesets on the remote. This commit plugs this gaping security hole by having the "batch" command perform permissions checking on each sub-command that is being batched. We do this by threading a permissions checking callable all the way to the protocol handler. The threading is a bit hacky from a code perspective. But it preserves API compatibility, which is the proper thing to do on the stable branch. One of the subtle things we do is assume that a command with an undefined permission is a "push" command. This is the safest thing to do from a security perspective: we don't want to take chances that a command could perform a write even though the server is configured to not allow writes. As the test changes demonstrate, it is no longer possible to bypass permissions via the "batch" wire protocol command. .. bc:: The "batch" wire protocol command now enforces permissions of each invoked sub-command. Wire protocol commands must define their operation type or the "batch" command will assume they can write data and will prevent their execution on HTTP servers unless the HTTP request method is POST, the server is configured to allow pushes, and the (possibly authenticated) HTTP user is authorized to perform a push.

wireproto: declare operation type for most commands (BC) (SEC) The permissions model of hgweb relies on a dictionary to declare the operation associated with each command - either "pull" or "push." This dictionary was established by d3147b4e3e8a in 2008. Unfortunately, we neglected to update this dictionary as new wire protocol commands were introduced. This commit defines the operations of most wire protocol commands in the permissions dictionary. The "batch" command is omitted because it is special and requires a more complex solution. Since permissions checking is skipped unless a command has an entry in this dictionary (this security issue will be addressed in a subsequent commit), the practical effect of this change is that various wire protocol commands now HTTP 401 if web.deny_read or web.allow-pull, etc are set to deny access. This is reflected by test changes. Note how various `hg pull` and `hg push` operations now fail before discovery. (They fail during the initial "capabilities" request.) This change fixes a security issue where built-in wire protocol commands would return repository data even if the web config were configured to deny access to that data. I'm on the fence as to whether we should HTTP 401 the capabilities request. On one hand, it can expose repository metadata and can tell callers things like what version of Mercurial the server is running. On the other hand, a client may need to know the capabilities in order to authenticate in a follow-up request. It appears that Mercurial clients handle the HTTP 401 on *any* protocol request, so we should be OK sending a 401 for "capabilities." But if this causes problems, it should be possible to allow "capabilities" to always work. .. bc:: Various read-only wire protocol commands now return HTTP 401 Unauthorized if the hgweb configuration denies read/pull access to the repository. Previously, various wire protocol commands would still work and return data if read access was disabled.

wireproto: move command permissions dict out of hgweb_mod The operation type associated with wire protocol commands is supposed to be defined in a dictionary so it can be used for permissions checking. Since this metadata is closely associated with wire protocol commands themselves, it makes sense to define it in the same module where wire protocol commands are defined. This commit moves hgweb_mod.perms to wireproto.PERMISSIONS and updates most references in the code to use the new home. The old symbol remains an alias for the new symbol. Tests pass with the code pointing at the old symbol. So this should be API compatible for extensions. As part of the code move, we split up the assignment to the dict so it is next to the @wireprotocommand. This reinforces that a @wireprotocommand should have an entry in this dict. In the future, we'll want to declare permissions as part of the @wireprotocommand decorator. But this isn't appropriate for the stable branch.

tests: comprehensively test HTTP server permissions checking We didn't have test coverage for numerous web.* config options. We add that test coverage. Included in the tests are tests for custom commands. We have commands that are supposedly read-only and perform writes and a variation of each that does and does not define its operation type in hgweb_mod.perms. The tests reveal a handful of security bugs related to permissions checking. Subsequent commits will address these security bugs.

tests: extract HTTP permissions tests to own test file We're about to implement a lot more coverage of the permissions mechanism. In preparation for that, establish a new test file to hold permissions checks. As part of this, we inline the important parts of the "req" helper function.

Added signature for changeset 369aadf7a326

Added tag 4.5.1 for changeset 369aadf7a326

revlog: resolve lfs rawtext to vanilla rawtext before applying delta This happens when a LFS delta base gets a non-LFS delta from another client. In that case, the LFS delta base needs to be converted to non-LFS version before applying the delta. Differential Revision: https://phab.mercurial-scm.org/D2069

revlog: do not use delta for lfs revisions This is similar to what we have done for changegroups. It is needed to make sure the delta application code path can assume deltas are always against vanilla (ex. non-LFS) rawtext so the next fix becomes possible. Differential Revision: https://phab.mercurial-scm.org/D2068

changegroup: do not delta lfs revisions There is no way to distinguish whether a delta base is LFS or non-LFS. If the delta is against LFS rawtext, and the client trying to apply it has the base revision stored as fulltext, the delta (aka. bundle) will fail to apply. This patch forbids using delta for LFS revisions in changegroup so bad deltas won't be transmitted. Note: this does not solve the problem entirely. It solves LFS delta applying to non-LFS base. But the other direction: non-LFS delta applying to LFS base is not solved yet. Differential Revision: https://phab.mercurial-scm.org/D2067

lfs: add a test showing bundle application could be broken When a bundle containing LFS delta uses non-LFS delta-base, or vice-versa, the bundle will fail to apply. Differential Revision: https://phab.mercurial-scm.org/D2066

test-annotate: set stdin and stdout to binary to get CR unmodified

test-annotate: rewrite sed with some python I hope this will fix the test failure seen on FreeBSD and Windows.

test-subrepo: glob away an unstable hash This is the instability mentioned at the beginning of the series. I don't like hiding it, but I don't want to sit on a fix for a user reported problem while trying to figure this out. The instability seems related to the cset with a .hgsub with a remote URL. (There's very little existing remote URL subrepo testing.)

subrepo: activate clone pooling to enable sharing with remote URLs This is the easiest way to ensure that repositories with remote subrepo references can share the subrepos, consistent with how local subrepos can be shared.

subrepo: don't attempt to share remote sources (issue5793) Untangling _abssource() to resolve the new subrepo relative to the shared parent's share path, and then either sharing from there (if it exists), or cloning to that location and then sharing, is probably more than should be attempted on stable. Absolute subrepo references are discouraged, so for now, this resumes the behavior prior to 68e0bcb90357 of cloning the absolute subrepo locally.

test-subrepo: demonstrate problems with subrepo sharing and absolute paths This affects remote paths in .hgsub, as well as clone pooling from a remote source. For reasons unknown, there are stability issues with the relative-path.t tests. If run as a single test, it is stable. If run with --loop, or with -jX for X>1, the hash of the parent repo changes. I'm seeing this on both Windows and Fedora 26. I added an `hg log --debug`, and the manifest hash changes, but I have no idea why.

annotate: do not poorly split lines at CR (issue5798) mdiff and lines(text) take only LF as a line separator, but str.splitlines() breaks our assumption. Use mdiff.splitnewlines() consistently. It's hard to read \r in tests, so \r is replaced with [CR]. I had to wrap sed by a shell function to silence check-code warning.

setup: only allow Python 3 from a source checkout (issue5804) People are running `pip install Mercurial` with Python 3 and that is working because not everything performs a Python version compatibility check. Modern versions of pip do recognize the "python_requires" keyword (https://packaging.python.org/tutorials/distributing-packages/#python-requires) which we set if using setuptools. But this isn't set nor recognized everywhere. To prevent people from accidentally installing Mercurial with Python 3 until Python 3 is officially supported, have setup.py fail when run with Python 3. But don't fail if we're running from a source checkout, as we don't want to anger Mercurial developers hacking on Python 3 nor Mercurial's test automation running from source checkouts. People running setup.py from source checkouts could still fall through a Python 3 crack. But at least the `pip install Mercurial` attempt will get nipped in the bud.

help: fix wording describing SSH requirements

graphlog: document what "_" and "*" mean Documenting "*" should've been a part of 9b3f95d9783d, but I somehow didn't notice that the symbols are explained in the command's help text.

tests: expand test coverage for updating phases Consolidating the tests demonstrated that there are behavior differences when pushing phases between bundle1 and bundle2. A reason for this is the behavior of legacy pushes where the client queries the state of phases and then conditionally updates phases after an "unbundle" is processed. This behavior is expected. The tests were incomplete because they only tested the case of a publishing repo. In this commit, we add a variant for a non-publishing repo. We still see some differences between the legacy and bundle2 exchanges. But they are less pronounced. The behavior of not firing a pushkey hook when phases are updated as part of changegroup application feels weird to me. I'm not sure if this is a feature or a bug. By the time the "pushkey" or "phases" bundle2 part is applied, the phases have already been moved on a publishing repository. We fire the "pushkey" hook regardless, even though it would be a no-op. This is the part that feels the most buggy.

tests: consolidate test-push-http.t and test-push-http-bundle1.t These tests were initially copies of each other. Now that we have #testcases support in .t tests, we can consolidate them. The changes to test-push-http.t reflect the differences between that file and test-push-http-bundle1.t. The variances in phases push behavior are the biggest differences. The test will be updated in a subsequent commit to make the differences more clear and to expand test coverage. For now, let's just port the differences verbatim to get the tests consolidated.

tests: port value-less unbundle capability test to test-push-http.t This test is present in test-push-http-bundle1.t. Let's add it to test-push-http.t to further unify the tests.

tests: add phase testing to test-push-http-bundle1.t test-push-http.t and test-push-http-bundle1.t were initially copies. Now that we have support for inline test variants, we can combine them. One of the variances between the tests is testing of phase moving. We add the missing code to test-push-http-bundle1.t.

date: fix parsing months Thanks nemo for discovering this on #mercurial IRC channel. Test Plan: Add a test. It fails before this patch: ``` + hg: parse error: invalid date: 'Feb 2018' + hg: parse error: invalid date: 'Apr 2018' + hg: parse error: invalid date: 'Jun 2018' + hg: parse error: invalid date: 'Sep 2018' + hg: parse error: invalid date: 'Nov 2018' ``` Differential Revision: https://phab.mercurial-scm.org/D2289

tests: allow age to go up to triple digits in test-shelve.t We started to glob the age of shelved changes in 51934fc796c0, which says that sometimes tests run slow and `hg shelve --list` says "2s" instead of "1s". However in some instances, like [1], tests run so slow that the age goes up to double digits ("13s" in that case). When that happens, `hg shelve --list` output has less white spaces after the age, so let's glob the spaces too. We probably won't ever need to handle triple digits there, but I went ahead and left only 2 required white spaces in total. [1]: https://buildd.debian.org/status/fetch.php?pkg=mercurial&arch=sparc64&ver=4.5-1&stamp=1518360804&raw=0

fileset: don't abort when running copied() on a revision with a removed file It looks like AND with any status-y fileset would trigger this, as added() and removed() also failed. The 4.5-rc revision is a convenient test case, but the merge isn't necessary.

Added signature for changeset d334afc585e2

Added tag 4.5 for changeset d334afc585e2

merge with i18n

i18n-pt_BR: synchronized with 373fb3f5922c

revset: evaluate filesets against each revision for 'file()' (issue5778) After f2aeff8a87b6, the fileset was evaluated to a set of files against the working directory, and then those files were applied against each revision. The result was nonsense. For example, `hg log -r 'file("set:exec()")'` on the Mercurial repo listed revision 0 because it has the `hg` script, which is currently +x. But that bit wasn't applied until revision 280 (which 'contains()' properly indicates). This technique was borrowed from checkstatus(), which services adds(), modifies(), and removes(), so it seems safe enough. The 'r:' case is explicitly assigned to wdirrev, freeing up rev=None to mean "re-evaluate at each revision". The distinction is important to avoid behavior changes with `hg log set:...` (test-largefiles-misc.t and test-fileset-generated.t drop current log output without this). I'm not sure what the right behavior for that is (1fd352aa08fc explicitly enabled this behavior for graphlog), but the day before the release isn't the time to experiment.

test-bookmarks-pushpull: stabilize for Windows

makefile: add Ubuntu Artful docker targets (.deb and ppa) Artful Aardvark was released on 2017-10-19 and will be supported until 2018-07.

bundle2: fix the formatting of the stream part requirements Use the same pre-encoded normalization as bundlespecs for the stream v2 part requirements. As it touch the wire protocol, it needs to change before the release. This was spotted by Gregory Szorc. Differential Revision: https://phab.mercurial-scm.org/D1950

streamclone: extract requirements formatting It will be reused for the formatting of the requirements of the stream v2 part requirement and later for the stream v2 requirements. Differential Revision: https://phab.mercurial-scm.org/D1949

bookmarks: fix pushkey compatibility mode (issue5777) The namespace used for the compatibility mode was missing a trailing 's'.

lazymanifest: avoid reading uninitialized memory I got errors running tests with clang UBSAN [1] enabled. One of them is: ``` --- test-dirstate.t +++ test-dirstate.t.err @@ -85,9 +85,115 @@ $ echo "[extensions]" >> .hg/hgrc $ echo "dirstateex=../dirstateexception.py" >> .hg/hgrc $ hg up 0 - abort: simulated error while recording dirstateupdates - [255] + mercurial/cext/manifest.c:781:13: runtime error: load of value 190, which is not a valid value for type 'bool' + #0 0x7f668a8cf748 in lazymanifest_diff mercurial/cext/manifest.c:781 + #1 0x7f6692fc1dc4 in call_function Python-2.7.11/Python/ceval.c:4350 + ....... + SUMMARY: UndefinedBehaviorSanitizer: invalid-bool-load mercurial/cext/manifest.c:781:13 in + [1] $ hg log -r . -T '{rev}\n' 1 $ hg status - ? a ``` While the code is not technically wrong, but switching the condition would make clang UBSAN happy. So let's do it. The uninitialized memory could come from, for example, `lazymanifest_copy` allocates `self->maxlines` items but only writes the first `self->lines` items. [1]: https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html Test Plan: Run `test-dirstate.t` with UBSAN and it no longer reports the issue. Differential Revision: https://phab.mercurial-scm.org/D1948

unamend: fix command summary line Before this patch, the docstring started with a newline, which led the summary line (shown in e.g. `hg help -c`) to be blank. Differential Revision: https://phab.mercurial-scm.org/D1943

configitems: traverse sections deterministically Otherwise output can be non-deterministic if there are warnings for multiple sections. Differential Revision: https://phab.mercurial-scm.org/D1947

lfs: don't require the .hglfs file to be tracked to control the policy The .hgignore file doesn't need to be tracked, nor does the git equivalent of this file. I'm still a little concerned about the effects of forgetting to commit this file. But the fact that conversions maintain the hashes if only the normal vs external storage changes, should make this less risky.

tests: add a pattern to fix --pure tests Test Plan: ran all tests with and without --pure, everything passed on gcc112. Differential Revision: https://phab.mercurial-scm.org/D1946