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

streamclone: add a comment about non-publishing being broken with v1 This change was suggested by Gregory Szorc.

streamclone: move requirement update into consumev2 This change was suggested by Gregory Szorc.

streamclone: use readexactly when reading stream v2 Yuya Nishihara pointed out that it is safer.

streamclone: rename '_emit' to '_emit2' for clarity This change was suggested by Gregory Szorc.

help: do not suggest "update --clean ." to cancel uncommitted merge Follows up 41ef02ba329b.

minifileset: note the unsupported file pattern when raising a parse error This was useful in debugging, because I stupidly quoted it out of habit from the command line. This isn't a great example that clearly shows the problem, but I don't know how to improve it. The problem *is* obvious once a complex statement or a clearly bogus string is used.

lfs: don't automatically exclude '.hg*' files from external tracking The only reasons I did this in the first place was because tracking externally seems like it would always be a mistake, and the eol extension does the same thing. Yuya and Jun thought it might be better to not do this[1], so I'll defer to them on this. If a problem with say, .hgtags or .hgeol does arise, it can be added back without breaking existing repos. [1] https://www.mercurial-scm.org/pipermail/mercurial-devel/2018-January/110371.html

lfs: rename {oid} to {lfsoid} Per Yuya, for consistency with {lfspointer}. It might be slightly confusing for there to be {lfsoid} and {lfspointer.oid}. But preventing ambiguity seems more important, and the latter is controlled by the git-lfs spec.

lfs: rename {pointer} to {lfspointer} Per Martin von Zweigbergk's suggestion to keep this unambiguous, for when it is migrated to {files} and friends.

Added signature for changeset 27b6df1b5adb

Added tag 4.5-rc for changeset 27b6df1b5adb

merge with stable to begin 4.5 freeze # no-check-commit because it's a clean merge

bundle2: increase payload part chunk size to 32kb Bundle2 payload parts are framed chunks. Esentially, we obtain data in equal size chunks of size `preferedchunksize` and emit those to a generator. That generator is fed into a compressor (which can be the no-op compressor, which just re-emits the generator). And the output from the compressor likely goes to a file descriptor or socket. What this means is that small chunk sizes create more Python objects and Python function calls than larger chunk sizes. And as we know, Python object and function call overhead in performance sensitive code matters (at least with CPython). This commit increases the bundle2 part payload chunk size from 4k to 32k. Practically speaking, this means that the chunks we feed into a compressor (implemented in C code) or feed directly into a file handle or socket write() are larger. It's possible the chunks might be larger than what the receiver can handle in one logical operation. But at that point, we're in C code, which is much more efficient at dealing with splitting up the chunk and making multiple function calls than Python is. A downside to larger chunks is that the receiver has to wait for that much data to arrive (either raw or from a decompressor) before it can process the chunk. But 32kb still feels like a small buffer to have to wait for. And in many cases, the client will convert from 8 read(4096) to 1 read(32768). That's happening in Python land. So we cut down on the number of Python objects and function calls, making the client faster as well. I don't think there are any significant concerns to increasing the payload chunk size to 32kb. The impact of this change on performance significant. Using `curl` to obtain a stream clone bundle2 payload from a server on localhost serving the mozilla-unified repository: before: 20.78 user; 7.71 system; 80.5 MB/s after: 13.90 user; 3.51 system; 132 MB/s legacy: 9.72 user; 8.16 system; 132 MB/s bundle2 stream clone generation is still more resource intensive than legacy stream clone (that's likely because of the use of a util.chunkbuffer). But the throughput is the same. We might be in territory we're this is effectively a benchmark of the networking stack or Python's syscall throughput. From the client perspective, `hg clone -U --stream`: before: 33.50 user; 7.95 system; 53.3 MB/s after: 22.82 user; 7.33 system; 72.7 MB/s legacy: 29.96 user; 7.94 system; 58.0 MB/s And for `hg clone --stream` with a working directory update of ~230k files: after: 119.55 user; 26.47 system; 0:57.08 wall legacy: 126.98 user; 26.94 system; 1:05.56 wall So, it appears that bundle2's stream clone is now definitively faster than legacy stream clone! Differential Revision: https://phab.mercurial-scm.org/D1932

bundle2: always advertise client support for stream parts Previously, enabling of stream clone over bundle2 was a server-side only change. And clients would only advertise bundle2 support for stream clones if an experimental config option was set. This situation wasn't forward compatible because in the future (when the feature is enabled on servers by default), an old client would send a request to the server but it wouldn't send its own bundle2 capability support for stream parts. Servers would have to infer that clients not sending this capability were old Mercurial clients that only sent the capability if the feature was explicitly enabled. Implicit and inferred behavior makes implementing servers hard. It's much better to be explicit about client features. We should either make the config option for bundle2 stream clones disable the feature client-side as well (so a server doesn't see a request from a client not advertising stream support). Or we should always advertise stream support if a client is willing to accept stream parts. Since I anticipating stabilizing stream clone support in bundle2 quickly, I think it's safe to always advertise client support in the bundle2 capabilities. So this commit changes things to do that. Because capabilities now vary between client and server, we had to create variations of the variable substitutions for those strings. Differential Revision: https://phab.mercurial-scm.org/D1931