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 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

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

exchange: don't send stream data when server.uncompressed is set Previously, bundle2 stream support would send out data even though the streaming clone feature was disabled. This commit changes the part handler to respect the server config. Differential Revision: https://phab.mercurial-scm.org/D1930

bundle2: don't advertise stream bundle2 capability when feature disabled The server.uncompressed config option can be used to disable streaming clones. While the top-level capability to advertise streaming clone support isn't advertised when this option is set, we were still sending the bundle2-level capabilities advertising support for stream parts. It makes sense to not advertise that support when streaming clones are globally disabled. If the structure of the new code seems a bit odd, it is because we'll have to further tweak the behavior in commit(s) ahead. Differential Revision: https://phab.mercurial-scm.org/D1929

tests: add more testing around server.uncompressed We already have testing for server.uncompressed in test-http*.t. However, it doesn't cover the new bundle2 use case. And, we don't have comprehensive testing of advertised capabilities. We add tests to test-clone-uncompressed.t that demonstrate behavior for both legacy and bundle2 configurations. If you look closely, the bundle2 capabilities are advertising stream support when it isn't enabled. That's a bug. In addition, while the client is smart enough to not request a stream clone when the server doesn't have the feature enabled, the getbundle wire protocol command is still sending stream clone data. This doesn't match the behavior of the legacy stream_out wire protocol command. That's also a bug. Tests have been added. While I was here, I also changed how the PID is recorded in $DAEMON_PIDS. If we kill a process, the PID formerly in $DAEMON_PIDS no longer exists. So we should replace that file instead of appending to it. Differential Revision: https://phab.mercurial-scm.org/D1928

bundle2: move version of stream clone into part name I don't like having version numbers as part parameters. It means that parts can theoretically vary wildly in their generation and processing semantics. I think that a named part should have consistent behavior over time. In other words, if you need to introduce new functionality or behavior, that should be expressed by inventing a new bundle2 part, not adding functionality to an existing part. This commit applies this advice to the just-introduced stream clone via bundle2 feature. The "version" part parameter is removed. The name of the bundle2 part is now "stream2" instead of "stream" with "version=v2". Differential Revision: https://phab.mercurial-scm.org/D1927

exchange: send bundle2 stream clones uncompressed Stream clones don't compress well. And compression undermines a point of stream clones which is to trade significant CPU reductions by increasing size. Building upon our introduction of metadata to communicate bundle information back to callers of exchange.getbundlechunks(), we add an attribute to the bundler that communicates whether the bundle is best left uncompressed. We return this attribute as part of the bundle metadata. And the wire protocol honors it when determining whether to compress the wire protocol response. The added test demonstrates that the raw result from the wire protocol is not compressed. It also demonstrates that the server will serve stream responses when the feature isn't enabled. We'll address that in another commit. The effect of this change is that server-side CPU usage for bundle2 stream clones is significantly reduced by removing zstd compression. For the mozilla-unified repository: before: 37.69 user 8.01 system after: 27.38 user 7.34 system Assuming things are CPU bound, that ~10s reduction would translate to faster clones on the client. zstd can decompress at >1 GB/s. So the overhead from decompression on the client is small in the grand scheme of things. But if zlib compression were being used, the overhead would be much greater. Differential Revision: https://phab.mercurial-scm.org/D1926

tests: update test to work with Git 2.16 It looks like Git 2.16 removed the "..." from some strings. Glob over those characters in the test output. Differential Revision: https://phab.mercurial-scm.org/D1935

exchange: return bundle info from getbundlechunks() (API) We generally want a mechanism to pass information about the generated bundle back to callers (in addition to the byte stream). Ideally we would return a bundler from this function and have the caller code to an interface. But the bundling APIs are not great and getbundlechunks() is the best API we have for obtaining bundle contents in a unified manner. We change getbundlechunks() to return a dict that we can use to communicate metadata. We populate that dict with the bundle version number to demonstrate some value. .. api:: exchange.getbundlechunks() now returns a 2-tuple instead of just an iterator. Differential Revision: https://phab.mercurial-scm.org/D1925

exchange: make stream bundle part deterministic repo.requirements is a set. We need to sort it so the part content is deterministic. Differential Revision: https://phab.mercurial-scm.org/D1924

bundle2: specify what capabilities will be used for We currently assume there is a symmetric relationship of bundle2 capabilities between client and server. However, this may not always be the case. We need a bundle2 capability to advertise bundle2 streaming clone support on servers to differentiate it from the existing, legacy streaming clone support. However, servers may wish to disable streaming clone support. If bundle2 capabilities were the same between client and server, a client (which may also be a server) that has disabled streaming clone support would not be able to perform a streaming clone itself! This commit introduces a "role" argument to bundle2.getrepocaps() that explicitly defines the role being performed. This will allow us (and extensions) to alter bundle2 capabilities depending on the operation being performed. Differential Revision: https://phab.mercurial-scm.org/D1923

wireproto: don't compress errors from getbundle() Errors should be small. There's no real need to compress them. Truth be told, there's no good reason to not compress them either. But leaving them uncompressed makes it easier to test failures by looking at the raw HTTP response. This makes it easier for us to write tests. It may make it easier for people writing their own clients. Differential Revision: https://phab.mercurial-scm.org/D1922

tests: teach get-with-headers.py some new tricks We add the ability to specify arbitrary HTTP request headers and to save the HTTP response body to a file. These will be used in upcoming commits. Differential Revision: https://phab.mercurial-scm.org/D1921

tests: use argparse in get-with-headers.py I'm about to add another flag and I don't want to deal with this organic, artisanal argument parser. Differential Revision: https://phab.mercurial-scm.org/D1920

convert: use a collections.deque This function was doing a list.pop(0) on a list whose length was the number of revisions to convert. Popping an early element from long lists is not an efficient operation. collections.deque supports efficient inserts and pops at both ends. So we switch to that data structure. When converting the mozilla-unified repository, which has 445,748 revisions, this change makes the "sorting..." step of `hg convert --sourcesort` significantly faster: before: ~59.2s after: ~1.3s Differential Revision: https://phab.mercurial-scm.org/D1934

repair: invalidate volatile sets after stripping Matt Harbison reported that some tests were broken on Windows after 1a09dad8b85a (evolution: report new unstable changesets, 2018-01-14). The failures were exactly as seen in this patch. The failures actually seemed correct, which made me wonder why they didn't fail the same way on Linux. It turned out to be a cache invalidation problem. The new orphan mentioned in the test case actually does get created when we're re-applying the temporary bundle that's created while stripping. However, without the invalidation, it appears that there was already an orphan before applying the temporary bundle. The warnings about unknown working parent appear because the aformentioned changeset means that we're now accessing the dirstate while it's invalid. We may want to suppress these messages that happen in the intermediate strip state, but they're technically correct (although confusing to the user), so I think just fixing the cache invalidation is fine for now. I haven't figured out why the caches seemed to get correctly invalidated on Windows. Differential Revision: https://phab.mercurial-scm.org/D1933

subrepo: handle 'C:' style paths on the command line (issue5770) If you think 'C:' and 'C:\' are equivalent paths, see the inline comment before proceeding. The problem here was that several commands that take a URL argument (incoming, outgoing, pull, and push) will use that value to set 'repo._subtoppath' on the repository object after command specific manipulation of it, but before converting it to an absolute path. When an operation is performed on a relative subrepo, subrepo._abssource() will posixpath.join() this value with the relative subrepo path. That adds a '/' after the drive letter, changing how it is evaluated by abspath()/realpath() in vfsmod.vfs(..., realpath=True) as the subrepo is instantiated. I initially tried sanitizing the path in url.localpath(), because url.isabs() only checks that it starts with a drive letter. By the sample behavior, this is clearly not an absolute path. (Though the comment in isabs() is weasely- this style path can't be joined either.) But not everything funnels through there, and it required explicitly calling localpath() in hg.parseurl() and assigning to url.path to fix. But then tests failed with urls like 'a#0'. Next up was sanitizing the path in the url constructor. That caused doctest failures, because there are drive letter tests, so those got expanded in system specific ways. Yuya correctly pointed out that util.url is a parser, and shouldn't be substituting the path too. Rather than fixing every command call site, just convert it in the common subrepo location. I don't see any sanitizing on the path config options, so I fixed those too. Note that while the behavior is fixed here, there are still places where 'comparing with C:' gets printed out, and that's not great for debugging purposes. (Specifically I saw it in `hg incoming -B C:`, without subrepos.) While clone will write out an absolute default path, I wonder what would happen if a user edited that path to be 'C:'. (I don't think supporting relative paths in .hgrc is a sane thing to do, but while we're poking holes in things...) Since this is such an oddball case, it still leaks through in places, and there seems to be a lot of duplicate url parsing, maybe the url parsing should be moved to dispatch, and provide the command with a url object? Then we could convert this to an absolute path once, and not have to worry about it in the rest of the code. I also checked '--cwd C:' on the command line, and it was previously working because os.chdir() will DTRT. Finally, one other note from the url.localpath() experimenting. I don't see any cases where 'self._hostport' can hold a drive letter. So I'm wondering if that is wrong/old code.

dummysmtpd: don't die on client connection errors The connection refused error in test-patchbomb-tls.t[1] is sporadic, but one of the more often seen errors on Windows. I added enough logging to a file and dumped it out at the end to make the following observations: - The listening socket is successfully created and bound to the port, and the "listening at..." message is always logged. - Generally, the following is the entire log output, with the "accepted ..." message having been added after `sslutil.wrapserversocket`: listening at localhost:$HGPORT $LOCALIP ssl error accepted connect accepted connect $LOCALIP from=quux to=foo, bar $LOCALIP ssl error - In the cases that fail, asyncore.loop() in the run() method is exiting, but not with an exception. - In the cases that fail, the following is logged right after "listening ...": Traceback (most recent call last): File "c:\\Python27\\lib\\asyncore.py", line 83, in read obj.handle_read_event() File "c:\\Python27\\lib\\asyncore.py", line 443, in handle_read_event self.handle_accept() File "../tests/dummysmtpd.py", line 80, in handle_accept conn = sslutil.wrapserversocket(conn, ui, certfile=self._certfile) File "..\\mercurial\\sslutil.py", line 570, in wrapserversocket return sslcontext.wrap_socket(sock, server_side=True) File "c:\\Python27\\lib\\ssl.py", line 363, in wrap_socket _context=self) File "c:\\Python27\\lib\\ssl.py", line 611, in __init__ self.do_handshake() File "c:\\Python27\\lib\\ssl.py", line 840, in do_handshake self._sslobj.do_handshake() error: [Errno 10054] $ECONNRESET$ - If the base class handler is overridden completely, the the first "ssl error" line is replaced by the stacktrace, but the other lines are unchanged. The client behaves no differently, whether or not the server stacktraced. In general, `./run-tests.py --local -j9 -t9000 test-patchbomb-tls.t --runs-per-test 20` would show the issue after a run or two. With this change, `./run-tests.py --local -j9 -t9000 test-patchbomb-tls.t --loop` ran 800 times without a hiccup. This makes me wonder if the other connection refused messages that bubble up on occasion are caused by a similar issue. It seems a bit drastic to kill the whole server on account of a single communication failure with a client. # no-check-commit because of handle_error() [1] https://buildbot.mercurial-scm.org/builders/Win7%20x86_64%20hg%20tests/builds/421/steps/run-tests.py%20%28python%202.7.13%29/logs/stdio

cext: define MIN macro only if it is not yet defined MIN macro is defined in <sys/param.h> on macOS Sierra. Therefore as HAVE_BSD_STATFS is defined in osutil.c, 'MIN' macro redefined warning is emitted.

copyright: update to 2018 January seems to be a good month to do this.

tests: glob copyright years in test-extension.t Other tests already do this.

test-sshserver: stabilize for Windows

test-branch-change: stabilize for Windows

test-sparse: make the '.hg' exclusion filter Windows compatible

lfs: rename {lfsattrs} to {pointer} This seems more descriptive.

lfs: expand the user facing documentation

streamclone: also stream caches to the client When stream clone is used over bundle2, relevant cache files are also streamed. This is expected to be a massive performance win for clone since no important cache will have to be recomputed. Some performance numbers: (All times are wall-clock times in seconds, 2 attempts per case.) # Mozilla-Central ## Clone over ssh over lan V1 streaming: 234.3 239.6 V2 streaming: 248.4 243.7 ## Clone over ssh over Internet V1 streaming: 175.5 110.9 V2 streaming: 109.1 111.0 ## Clone over HTTP over lan V1 streaming: 105.3 105.6 V2 streaming: 112.7 111.4 ## Clone over HTTP over internet V1 streaming: 105.6 114.6 V2 streaming: 226.7 225.9 ## Hg tags V1 streaming (no cache): 1.084 1.071 V2 streaming (cache): 0.312 0.325 ## Hg branches V1 streaming (no cache): 14.047 14.148 V2 streaming (with cache): 0.312 0.333 # Pypy ## Clone over ssh over internet V1 streaming: 29.4 30.1 V2 streaming: 31.2 30.1 ## Clone over http over internet V1 streaming: 29.7 29.7 V2 streaming: 75.2 72.9 (since ssh and lan are not affected, there seems to be an issue with how we read/write the http stream on connection with latency, unrelated to the format) ## Hg tags V1 streaming (no cache): 1.752 1.664 V2 streaming (with cache): 0.274 0.260 ## Hg branches V1 streaming (no cache): 4.469 4.728 V2 streaming (with cache): 0.318 0.321 # Private repository: * 500K revision revisions * 11K topological heads * 28K branch heads ## hg tags no cache: 1543.332 with cache: 4.900 ## hg branches no cache: 91.828 with cache: 2.955

caches: make 'cachetocopy' available in scmutil For more code to use this information, we need it to be more publicly available.

streamclone: add support for cloning non append-only file The phaseroots are stored in a non append-only file in the repository. We include them in the stream too. Since they are not append-only, we have to keep a copy around while we hold the lock to be able to stream them later. Since phase get exchanged within the stream we can skip requesting them independently. As a side effect, this will fixes issue5648 once the feature is enabled by default.

streamclone: tests phase exchange during stream clone We add a test dedicated to phases. As reported in issue 5648 stream from a non publishing server is currently broken (does not preserve the phase). We'll fix it with 'v2' support in the next changesets.

streamclone: add support for bundle2 based stream clone The feature put to use the various bits introduced previously. If the server supports it, the client will request its stream clone through bundle2 instead of the legacy 'stream_out' commands. The bundle2 version use the better 'v2' version of stream bundles. The 'v2' format is not finalized yet. Now that there are some code running it, we can start working on it again. Performance numbers are available at the end of this series.

pull: preindent some code Next changesets will add support for using stream cloning with bundle2. We introduce indentation change first for clarity.

pull: reorganize bundle2 argument bundling We are about to add the ability to use stream bundle with bundle2. Before doing so, we need to gather some code that will not be used in the bundle2 case. There is no behavior change within this changeset.

clone: allow bundle2's stream clone with 'server.disablefullbundle' The previous check was a bit too strict and would not recognize a get bundle not requesting changegroup.

bundle2: add support for a 'stream' parameter to 'getbundle' This parameter can be used to request a stream bundle.

bundle2: add a 'stream' part handler for stream cloning The part contains the necessary arguments and payload to handle a stream bundle v2. It will be put to use in later changesets.

streamclone: rework canperformstreamclone There is code about bundle2 laying around in `canperformstreamclone` but not put to any uses. As we discovered with the previous patch, streambundle 'v1' won't work on bundle2 because they are readline based. So we jump to 'v2' as the first expected supported version.

streamclone: define first iteration of version 2 of stream format (This patch is based on a first draft from Gregory Szorc, with deeper rework) Version 1 of the stream clone format was invented many years ago and suffers from a few deficiencies: 1) Filenames are stored in store-encoded (on filesystem) form rather than in their internal form. This makes future compatibility with new store filename encodings more difficult. 2) File entry "headers" consist of a newline of the file name followed by the string file size. Converting strings to integers is avoidable overhead. We can't store filenames with newlines (manifests have this limitation as well, so it isn't a major concern). But the big concern here is the necessity for readline(). Scanning for newlines means reading ahead and that means extra buffer allocations and slicing (in Python) and this makes performance suffer. 3) Filenames aren't compressed optimally. Filenames should be compressed well since there is a lot of repeated data. However, since they are scattered all over the stream (with revlog data in between), they typically fall outside the window size of the compressor and don't compress. 4) It can only exchange stored based content, being able to exchange caches too would be nice. 5) It is limited to a stream-based protocol and isn't suitable for an on-disk format for general repository reading because the offset of individual file entries requires scanning the entire file to find file records. As part of enabling streaming clones to work in bundle2, #2 proved to have a significant negative impact on performance. Since bundle2 provides the opportunity to start fresh, Gregory Szorc figured he would take the opportunity to invent a new streaming clone data format. The new format devised in this series addresses #1, #2, and #4. It punts on #3 because it was complex without yielding a significant gain and on #5 because devising a new store format that "packs" multiple revlogs into a single "packed revlog" is massive scope bloat. However, this v2 format might be suitable for streaming into a "packed revlog" with minimal processing. If it works, great. If not, we can always invent stream format when it is needed. This patch only introduces the bases of the format. We'll get it usable through bundle2 first, then we'll extend the format in future patches to bring it to its full potential (especially #4).

util: implement varint functions This will be useful in an incoming version-2 of the stream format.

util: move 'readexactly' in the util module This function is used in multiple place, having it in util would be better. (existing caller will be migrated in another series)

lfs: separate a debug message from the subsequent abort message

sshserver: add a couple of tests for argument parsing I noticed that we didn't have any unit tests covering wire protocol argument parsing.

merge with stable

wireproto: split streamres into legacy and modern case A couple of commands currently require transmission of uncompressed frames with the old MIME type. Split this case from streamres into a new streamres_legacy class. Streamline the remaining code accordingly. Add a new flag to streamres to request uncompressed streams. This is useful for sending data that is already compressed like a pre-built bundle. Expect clients to support uncompressed data. For older clients, zlib will still be used. Differential Revision: https://phab.mercurial-scm.org/D1862

localrepo: run cache-warming transaction callback before report callback See in-code comment for details. Differential Revision: https://phab.mercurial-scm.org/D1918

scmutil: 0-pad transaction report callback category Before this patch, the transaction name was '%2i-txnreport', which means the first one would be ' 0-txnreport'. It seems more intuitive for sorting purposes (the callbacks are called in lexicographical order) to make it 0-padded. Differential Revision: https://phab.mercurial-scm.org/D1917

stream: add a test showing we also clone bookmarks Bookmarks are not stored in `.hg/store`. We need to make sure they are cloned with `--stream`.

branch: allow changing branch name to existing name if possible With the functionality added in previous patch we can change branches of a revision but not everytime even if it's possible to do so. For example cosider the following case: o 3 added a (foo) o 2 added b (foo) o 1 added c (bar) o 0 added d (bar) Here if I want to change the branch of rev 2,3 to bar, it was not possible and it will say, "a branch with same name exists". This patch allows us to change branch of 2,3 to bar. The underlying logic for changing branch finds the changesets from the revs passed which have no parents in revs. We only support revsets which have only one such root, so to support this we check whether the parent of the root has the same name as that of the new name and if so, we can use the new name to change branches. Differential Revision: https://phab.mercurial-scm.org/D1913

branch: add a --rev flag to change branch name of given revisions This patch adds a new --rev flag to hg branch which can be used to change branch of revisions. This is motivated from topic extension where you can change topic on revisions but this one has few restrictions which are: 1) You cannot change branch name in between the stack 2) You cannot change branch name and set it to an existing name 3) You cannot change branch of non-linear set of commits 4) You cannot change branch of merge commits. Tests are added for the same. .. feature:: An experimental flag `--rev` to `hg branch` which can be used to change branch of changesets. Differential Revision: https://phab.mercurial-scm.org/D1074

templater: fix crash by empty group expression 'exp' may be None because of '(group None)' node. The error message is copied from revset.py.

log: fix typo in comment about _matchfiles()

sparse: --include 'dir1/dir2' should not include 'dir1/*' In 2015 there was a workaround added (f39bace2d6cad32907c0d7961b3c0dbd64a1b7ad) to sparse in the hg-experimental repo. That workaround: a) no longer seems to be needed, since its testcase passes even with the code removed, and b) caused a new problem: --include 'dir1/dir2' ended up including dir1/* too. (--include 'glob:dir1/dir2' is a user-level workaround.) Remove the offending code, and add a testcase for situation B.

fileset: add kind:pat operator ":" isn't taken as a symbol character but an infix operator so we can write e.g. "path:'foo bar'" as well as "'path:foo bar'". An invalid pattern kind is rejected in the former form as we know a kind is specified explicitly. The binding strength is copied from "x:y" range operator of revset. Perhaps it can be adjusted later if we want to parse "foo:bar()" as "(foo:bar)()", not "foo:(bar())". We can also add "kind:" postfix operator if we want. One possible confusion is that the scope of the leading "set:" vs "kind:pat" operator. The former is consumed by a matcher so applies to the whole fileset expression: $ hg files 'set:foo() or kind:bar or baz' ^^^^^^^^^^^^^^^^^^^^^^^^ Whereas the scope of kind:pat operator is narrow: $ hg files 'set:foo() or kind:bar or baz' ^^^

minifileset: unify handling of symbol and string patterns They must be identical for fileset compatibility.

fileset: move import of match module to top Actually there was no circular import issue.

revlog: group delta computation methods under _deltacomputer object Extracting these methods from revlog will allow changing the implementation of the deltacomputer, by providing this interface: __init__(self, revlog) - constructor that initialize the object from a given revlog buildtext(self, revinfo, fh) - builds the fulltext version of a revision from a _revisioninfo object and the file handle to the .d (or .i for inline mode) file. finddeltainfo(self, revinfo, fh) - find a revision in the revlog against which it is acceptable to build a delta, and build the corresponding _deltainfo. It should now be easier to write an experimental feature that would replace _deltacomputer by another object, for example one that would know how to parallelize the delta computation in order to quicken the storage of multiple revisions.

revlog: refactor out _finddeltainfo from _addrevision Splicing the code into smaller chunks should help understanding it, and eventually override some parts in experimental branches to try optimization.

localrepo: micro-optimize __len__() to bypass repoview Since len(changelog) isn't overridden, we don't have to validate a cache of unfiltered changelog. $ python -m timeit -n 10000 \ -s 'from mercurial import hg, ui; repo = hg.repository(ui.ui());' \ 'len(repo)' orig) 10000 loops, best of 3: 32.1 usec per loop new) 10000 loops, best of 3: 1.79 usec per loop Spotted by Jordi Gutiérrez Hermoso.

lfs: defer registering the pre-push hook until blobs are committed The hook searches outgoing commits for blobs, and uploads them before letting the push occur. No reason to search for that which isn't there.

lfs: dump the full response on httperror in debug mode This was immensely helpful in diagnosing the 500: Internal Server Error when using workers to upload. It's a nasty wall of html, so we really can't do anything else with it.

lfs: default the User-Agent header for blob transfers to 'git-lfs' The custom User-Agent for blob transfers was added in e7bb5fc4570c. Now I've hit another incompatibility with a server wanting the string to start with 'git' or 'git-lfs' [1]. I don't feel strongly about this either way, but a Wireshark trace of git shows that when the Batch API is hit, the User-Agent is 'git-lfs/2.3.4'. So this would probably ensure maximum interoperability. This still leaves the experimental knob in, just in case. [1] https://bitbucket.org/sdorra/scm-manager/src/095a027178888bc2b819aebfae3d2c192c858030/scm-plugins/scm-git-plugin/src/main/java/sonia/scm/web/GitUserAgentProvider.java?at=default&fileviewer=file-view-default#GitUserAgentProvider.java-117

lfs: default to not using workers for upload/download I ran into truncated uploads with this defaulting to on. Wojciech Lis diagnosed it as creating keepalive connections prior to forking, and illegally multiplexing the same connection. [1] I didn't notice a problem with the couple of downloads I tried, but disabled both for simplicity and safety. [1] https://www.mercurial-scm.org/pipermail/mercurial-devel/2018-January/109916.html

lfs: add the '{lfsattrs}' template keyword to '{lfs_files}' This provides access to the metadata dictionary contained within the tracked pointer file. The OID is probably the most important attribute, and has its own keyword. But we might as well have this for completeness. I liked {pointer} better, but couldn't make it work with the singular/plural forms.

debugdownload: read repository hgrc if there is one The command does not require a repository, but will use it if there is one. This simplifies the reading of the remote destination when testing for largefile based url.

test-blackbox: stabilize for Windows This goes with 853bf7d90804.

debugdeltachain: cleanup the double call to _slicechunk Follow-up to Yuya's review on 43154a76f3927c4f0c8c6b02be80f0069c7d8fdb: > Nit: hasattr() isn't necessary. revlog._slicechunk() is used in the previous > block. hasattr() isn't necessary indeed, as we are protected by the withsparseread option, which was introduced at the same time as revlog._slicechunk, in e2ad93bcc084b97c48f54c179365376edb702858. And, as Yuya noticed, _slicechunk could be called only once.

blackbox: don't unpack the list while passing into str.join() The current state may result in error TypeError. Caught using evolve-tests.

atomicupdate: add an experimental option to use atomictemp when updating In some cases Mercurial truncating files when updating causes problems. It can happens when processes are currently reading the file or with big file or on NFS mounts. We add an experimental option to use the atomictemp option of vfs.__call__ in order to avoid the problem. The localrepository.wwrite seems to assume the files are created without the `x` flag; with atomictempfile, the new file might inherit the `x` flag from the destination. We force remove it afterward. This code could be refactored and the flag processing could be moved inside vfs. This patch should be tested with `--extra-config-opt experimental.update.atomic-file=True` as we disabled the option by default. Differential Revision: https://phab.mercurial-scm.org/D1882

write: add the possibility to pass keyword argument from batchget to vfs We are going to pass atomictemp keyword argument from merge.baychget to vfs.__call__. Update all the frames to accept **kwargs and pass it to the next function. Differential Revision: https://phab.mercurial-scm.org/D1881

blackbox: if --debug is used, also trace ui.debug() calls Differential Revision: https://phab.mercurial-scm.org/D1880

bdiff: handle the possibility of overflow when computing allocation size Differential Revision: https://phab.mercurial-scm.org/D1904

phabricator: add a template item for linking to a differential review Differential Revision: https://phab.mercurial-scm.org/D1802

githelp: don't reference 3rd party commands for `git show` `hg show` is a Facebook-ism. Reference functionality in core. The logic here isn't terrific. But it is better than nothing. Differential Revision: https://phab.mercurial-scm.org/D1729

githelp: improve help for "reset" The previous help referenced a `hg reset`, which is a Facebook-ism. We convert that to `hg update`. We also recognize --soft. Differential Revision: https://phab.mercurial-scm.org/D1728

githelp: clean up reflog help This referenced commands that don't exist in core. The new help isn't great since it references an experimental extension. But it is better than nothing. While we're here, also add test coverage. Differential Revision: https://phab.mercurial-scm.org/D1727

githelp: replace suggestion of `hg record` `hg record` is deprecated in favor of `hg commit --interactive`. Differential Revision: https://phab.mercurial-scm.org/D1726

githelp: remove reference to tweakdefaults This is a Facebook-ism. Differential Revision: https://phab.mercurial-scm.org/D1725

githelp: recommend `hg import` for `git am` This referenced a third party extension. It doesn't feel appropriate to do that from a core extension. Reference `hg import` instead. Differential Revision: https://phab.mercurial-scm.org/D1724

githelp: improve help for `git add` The old code was referencing record and crecord, which are deprecated. `hg commit --interactive` is the preferred mechanism to use. In addition, there was duplicate code in this function. It has been removed. Tests have been added to cover this function. Differential Revision: https://phab.mercurial-scm.org/D1723

githelp: vendor Facebook authored extension This commit vendors the Facebook-authored "githelp" extension. This extension provides a "githelp" command that can be used to try to convert a `git` command to its Mercurial equivalent. This functionality is useful for Git users learning Mercurial. The extension was copied from the repository at revision 32ceeccb832c433b36e9af8196814b8e5a526775. The following modifications were made: * The "testedwith" value has been changed to match core's conventions. * Support for a custom footer has been removed, as it is Facebook specific. The feature is useful. But the implementation wasn't appropriate for core. * A test referencing "tweakdefaults" has been removed. * Imports changed to match Mercurial's style convention. * Double newlines in test removed. * Pager activation changed to ui.pager(). * Initial line of githelp.py changed to add description of file. The removal of the custom footer code was the only significant source change. The rest were mostly cosmetic. There are still some Facebook-isms in the extension. I'll address these as follow-ups. .. feature:: githelp extension The "githelp" extension provides the ``hg githelp`` command. This command attempts to convert a ``git`` command to its Mercurial equivalent. The extension can be useful to Git users new to Mercurial. Differential Revision: https://phab.mercurial-scm.org/D1722

merge: use public interface ms.localctx instead of ms._local

bookmarks: display the obsfate of hidden revision we create a bookmark on Display the same message we added recently to the filtered error message create a bookmark on an hidden revision. Differential Revision: https://phab.mercurial-scm.org/D1870

update: display the obsfate of hidden revision we update to Display the same message we added recently to the filtered error message when updating to a hidden obsolete changeset. Differential Revision: https://phab.mercurial-scm.org/D1869

evolution: make reporting of new unstable changesets optional This makes it possible to turn off the reporting of unstable changesets (e.g. "1 new orphan changesets"), just in case it's too slow for some users. Anyone who's been using the evolve extension has already been accepting the cost of the reporting, so this is just for the few users who have turned on obsmarkers but not been using the evolve extension (as I believe Facebook has). Differential Revision: https://phab.mercurial-scm.org/D1868

evolution: report new unstable changesets This adds a transaction summary callback that reports the number of new orphan, content-divergent and phase-divergent changesets. The code for reporting it is based on the code from the evolve extension, but simplified a bit. It simply counts the numbers for each kind of instability before and after the transaction. That's obviously not very efficient, but it's easy to reason about, so I'm doing this as a first step that can make us quite confident about the test case changes. We can optimize it later and make sure that the tests are not affected. The code has been used in the evolve extension for a long time and has apparently been sufficiently fast, so it doesn't seem like a pressing issue. Unlike the evolve extension's version of this report, this version applies to all commands (or all transactions run as part of any command, to be exact). Differential Revision: https://phab.mercurial-scm.org/D1867

transaction: register summary callbacks only at start of transaction (BC) We currently register summary callbacks every time localrepo.transaction() is called, so both when the transaction is started and when a nested transaction is created. That seems a little weirdly asymmetric, because the summary callbacks are thus not necessarily registred at the beginning of the outermost transaction, but they are only called when the outermost transaction closes (not when a nested transaction closes). I want to add another summary callback that records the repo state at the beginning of the transaction and compares to that when the transaction closes. However, because of the registration that happens when a nested transaction is created, that would need to go through extra trouble to not overwrite the callback and report the difference from the start time of the innermost transaction to the close of the outermost transaction. Also, the callbacks are registered with a name based on the order they are defined in the registersummarycallback(). For example, if both the "new changesets %s" and the "obsoleted %i changesets" hooks are registered, the first would be called 00-txnreport and the second would be called 01-txnreport. That gets really weird if registersummarycallback() gets called multiple times, because the last one wins, and a depending on which of the two callbacks get registered, we might hypothetically even overwrite on type of callback with another. For example, if when the outer transaction was started, we registered the "new changesets %s" callback first, and when the inner transaction was started, we registered only the "obsoleted %i changesets" callback, then only the latter message would get printed. What makes it hypothetical is that what gets registered depends on the transaction name, and the set of transaction names that we match on for the former latter message is a subset of the set of names we match on for the former. Still, that seems like a bug waiting to happen. That second issue could be solved independently, but the first issue seems enough for me to consider it a bug (affecting developers, not users), so this patch simply drops that extra registration. Note that this affects "hg transplant" in a user-visible way. When "hg transplant" is asked to transplant from a remote repo so it involves a pull, then the outermost transaction name is "transplant" and an inner transaction is created for "pull". That inner transaction is what led us to sometimes report "new changesets %s" from "hg transplant". After this patch, that no longer happens. That seems fine to me. We can make it instead print the message for all "hg transplant" invocations if we want (not just those involving a remote), but I'll leave that for someone else to do if they think it's important. Differential Revision: https://phab.mercurial-scm.org/D1866

repair: filter out unknown revisions from phasecache within transaction I'm about to add another summary report callback that needs to access phase information. These callbacks run at the end of the transaction and some of them failed because they tried to get the phase for stripped commits. The solution is to filter out unknown revisions before the transaction is closed. Differential Revision: https://phab.mercurial-scm.org/D1865

repair: drop unnecessary phase cache invalidation After stripping the revlogs, we have been invalidating the phase cache since bf7b8157c483. Later, in 8e3021fd1a44, I added a call to phasecache.filterunknown(). I apparently didn't realize it then, but I now think that that call made the existing phasecache.invalidate() call unnecessary, so this patch drops it. Both the test added in bf7b8157c483 and the entire evolve extension test suite indeed still pass. Differential Revision: https://phab.mercurial-scm.org/D1864