f1186c292d03e2608b59be1b576ec7bca1ba0d56: verify: make output less confusing (issue5924)
Meirambek Omyrzak <meirambek77@gmail.com> - Wed, 05 Sep 2018 01:19:48 +0300 - rev 49393
Push 910 by gszorc@mozilla.com at Mon, 10 Sep 2018 16:58:43 +0000
verify: make output less confusing (issue5924) output before: "500 files, 2035 changesets, 2622 total revisions" output after: "checked 2035 changesets with 2622 changes to 500 files" new one was suggested in the comments inside the issue. Differential Revision: https://phab.mercurial-scm.org/D4476
d629b6d2f05ac79bcb57f25042e4273cedcf08b3: revlog: clarify the comment attached to delta reuse
Boris Feld <boris.feld@octobus.net> - Tue, 04 Sep 2018 21:28:28 +0200 - rev 49392
Push 910 by gszorc@mozilla.com at Mon, 10 Sep 2018 16:58:43 +0000
revlog: clarify the comment attached to delta reuse The previous version was a bit complicated and referred to a deprecated configuration option.
931386a0b108ed3be9d979e684e7c37b6a014fe3: revlog: drop duplicated code
Boris Feld <boris.feld@octobus.net> - Tue, 04 Sep 2018 21:05:21 +0200 - rev 49391
Push 910 by gszorc@mozilla.com at Mon, 10 Sep 2018 16:58:43 +0000
revlog: drop duplicated code This code probably got duplicated by a rebase/evolve conflict. We drop the extra copy, the other copy is right below. This had no real effects since other logic ensure that we never test the same revision twice.
43d92d68ac889eed34e6223bdc0298bc4f056592: wireprotov2peer: properly format errors
Gregory Szorc <gregory.szorc@gmail.com> - Wed, 05 Sep 2018 09:04:40 -0700 - rev 49390
Push 910 by gszorc@mozilla.com at Mon, 10 Sep 2018 16:58:43 +0000
wireprotov2peer: properly format errors formatrichmessage() expects an iterable containing dicts with well-defined keys. We were passing in something else. This caused an exception. Change the code to call formatrichmessage() with the proper argument. And add a TODO to potentially emit the proper data structure from the server in the first place. Differential Revision: https://phab.mercurial-scm.org/D4441
42bc1c70a6b83ee78440e8a81b7ff7466137362c: wireprotov2peer: report exceptions in frame handling against request future
Gregory Szorc <gregory.szorc@gmail.com> - Thu, 23 Aug 2018 13:50:47 -0700 - rev 49389
Push 910 by gszorc@mozilla.com at Mon, 10 Sep 2018 16:58:43 +0000
wireprotov2peer: report exceptions in frame handling against request future Otherwise the future may never resolve, which could cause deadlock. Differential Revision: https://phab.mercurial-scm.org/D4440
98995b689e03fd3d39ace0799d7357d4edba9ef5: httppeer: use util.readexactly() to abort on incomplete responses
Anton Shestakov <av6@dwimlabs.net> - Sat, 08 Sep 2018 21:58:51 +0800 - rev 49388
Push 910 by gszorc@mozilla.com at Mon, 10 Sep 2018 16:58:43 +0000
httppeer: use util.readexactly() to abort on incomplete responses Plain resp.read(n) may not return exactly n bytes when we need, and to detect such cases before trying to interpret whatever has been read, we can use util.readexactly(), which raises an Abort when stream ends unexpectedly. In the first case here, readexactly() prevents a traceback with struct.error, in the second it avoids looking for invalid compression engines. In this test case, _wraphttpresponse doesn't catch the problem (presumably because it doesn't know transfer encoding), and the code continues reading the response until it gets to compression engine data. Maybe there should be checks before the execution gets there, but I'm not sure where (httplib?)
1fc39367eafda83e757d99cc16164c0fbc8fd63a: httppeer: calculate total expected bytes correctly
Anton Shestakov <av6@dwimlabs.net> - Sat, 08 Sep 2018 23:57:07 +0800 - rev 49387
Push 910 by gszorc@mozilla.com at Mon, 10 Sep 2018 16:58:43 +0000
httppeer: calculate total expected bytes correctly User-facing error messages that handled httplib.IncompleteRead errors in Mercurial used to look like this: abort: HTTP request error (incomplete response; expected 3 bytes got 1) But the errors that are being handled underneath the UI look like this: IncompleteRead(1 bytes read, 3 more expected) I.e. the error actually counts total number of expected bytes minus bytes already received. Before, users could see weird messages like "expected 10 bytes got 10", while in reality httplib expected 10 _more_ bytes (20 in total).
77a2f6d805f2044e7fe5c85ed217070a4dc6de8d: lazyancestors: reuse __iter__ implementation in __contains__
Martin von Zweigbergk <martinvonz@google.com> - Fri, 07 Sep 2018 23:36:09 -0700 - rev 49386
Push 910 by gszorc@mozilla.com at Mon, 10 Sep 2018 16:58:43 +0000
lazyancestors: reuse __iter__ implementation in __contains__ There was a comment in the code that said "Trying to do both __iter__ and __contains__ using the same visit heap and seen set is complex enough that it slows down both. Keep them separate.". However, it seems easy and efficient to make __contains__ keep an iterator across calls. I couldn't measure any slowdown from `hg bundle --all` (which seem to call lazyancestors.__contains__ frequently). Differential Revision: https://phab.mercurial-scm.org/D4508
b6a0e06b0f7d6884e743fef61fd53b44507daed3: lazyancestors: extract __iter__ to free function
Martin von Zweigbergk <martinvonz@google.com> - Sun, 09 Sep 2018 23:16:55 -0700 - rev 49385
Push 910 by gszorc@mozilla.com at Mon, 10 Sep 2018 16:58:43 +0000
lazyancestors: extract __iter__ to free function The next patch will keep a reference to the returned iterator in a field, which would otherwise result in a reference cycle. Differential Revision: https://phab.mercurial-scm.org/D4517
89630d0b3e23305d5b667c6f507706b4e208bf32: phase: report number of non-public changeset alongside the new range
Boris Feld <boris.feld@octobus.net> - Thu, 30 Aug 2018 01:53:21 +0200 - rev 49384
Push 910 by gszorc@mozilla.com at Mon, 10 Sep 2018 16:58:43 +0000
phase: report number of non-public changeset alongside the new range When interacting with non-publishing repository or bundle, it is useful to have some information about the phase of the changeset we just pulled. This changeset updates the "new changesets MIN:MAX" output to also includes phases information for non-public changesets. Displaying extra data about non-public changesets means the output for exchange with publishing repository (the default) is unaffected.
3ba87d5b9ad3f4fda6c5d952aba02b01670dad0f: tests: disable test-nointerrupt on Windows
Matt Harbison <matt_harbison@yahoo.com> - Fri, 07 Sep 2018 23:54:42 -0400 - rev 49383
Push 910 by gszorc@mozilla.com at Mon, 10 Sep 2018 16:58:43 +0000
tests: disable test-nointerrupt on Windows Per the followup discussion[1]. proc.send_signal(INT) in timeout.py raises a ValueError because of an unsupported signal. I don't like missing test coverage for this on Windows. But this is the last test failing on Windows, and red all the time hides new failures. [1] https://phab.mercurial-scm.org/D3716
c4a7ba10cdd7da058627e23c461ecbe7240a789c: tests: conditionalize an error message about unlinking a non empty directory
Matt Harbison <matt_harbison@yahoo.com> - Fri, 07 Sep 2018 23:39:49 -0400 - rev 49382
Push 910 by gszorc@mozilla.com at Mon, 10 Sep 2018 16:58:43 +0000
tests: conditionalize an error message about unlinking a non empty directory The message on Windows comes from win32.unlink(). It looks like os.unlink() on posix platforms is a simple call to unlink(3), which turns into unlinkat(2). Since there's a comment in one of the tests that the message should be improved, I don't think it's worth adding a check in win32.unlink() to see if it's empty, if that function is always going to fail on a directory. (It seems like the POSIX spec allows unlinking directories though.)
8eb2145ff0fb2257eaec40f9bfcbd332bedea820: ancestors: add nullrev to set from the beginning
Martin von Zweigbergk <martinvonz@google.com> - Fri, 07 Sep 2018 14:48:38 -0700 - rev 49381
Push 910 by gszorc@mozilla.com at Mon, 10 Sep 2018 16:58:43 +0000
ancestors: add nullrev to set from the beginning Differential Revision: https://phab.mercurial-scm.org/D4507
7eadc94078675a19066cf73ac2d25403b9551cae: ancestor: filter out initial revisions lower than stoprev
Yuya Nishihara <yuya@tcha.org> - Sat, 08 Sep 2018 10:59:24 +0900 - rev 49380
Push 910 by gszorc@mozilla.com at Mon, 10 Sep 2018 16:58:43 +0000
ancestor: filter out initial revisions lower than stoprev
431068d7e9db6b0f40c77d38c229970b21c289c9: ancestor: add test showing inconsistency between __iter__ and __contains__
Yuya Nishihara <yuya@tcha.org> - Sat, 08 Sep 2018 10:48:42 +0900 - rev 49379
Push 910 by gszorc@mozilla.com at Mon, 10 Sep 2018 16:58:43 +0000
ancestor: add test showing inconsistency between __iter__ and __contains__
7e26011973904686a7fbe0113ce03d79cf09993c: localrepo: split obviously mutable components out of localrepository draft orphan
Gregory Szorc <gregory.szorc@gmail.com> - Fri, 07 Sep 2018 18:29:48 -0700 - rev 49377
Push 909 by gszorc@mozilla.com at Sat, 08 Sep 2018 01:41:49 +0000
localrepo: split obviously mutable components out of localrepository I want to make local repository object construction more... dynamic. e.g. as part of opening repositories, I want to look at their requirements / features and dynamically construct a repository instance suitable for that repository. We introduced an "intents" system a few releases ago. Essentially, the thing requesting a new repository or peer instance can say what it "intends" to do. One of the intents indicates the operation will be read-only. Various commands are already annotated to indicate that they are read-only. This commit is the first step towards doing something with the intents system and making repository construction more dynamic. We split the attributes and methods that are obviously related to modifying a repository to a separate class and interface. localrepository inherits from this new class, so nothing should meaningfully change in this commit other than moving a bunch of code around and hooking up the class inheritance.
68b842e2723d142499bcde5679bf81ccb378a93c: hg: allow extra arguments to be passed to repo creation draft obsolete
Gregory Szorc <gregory.szorc@gmail.com> - Fri, 07 Sep 2018 17:27:17 -0700 - rev 49374
Push 909 by gszorc@mozilla.com at Sat, 08 Sep 2018 01:41:49 +0000
hg: allow extra arguments to be passed to repo creation Currently, repository creation is influenced by consulting the ui instance and turning config options into requirements. This means that in order to influence repository creation, you need to define and set a config option and that the option must translate to a requirement stored in the .hg/requires file. This commit introduces a new mechanism to influence repository creation. hg.repository() and hg.peer() have been taught to receive a new optional argument defining extra options to apply to repository creation. This value is passed along to the various instance() functions and can be used to influence repository creation. This will allow us to e.g. configure a repository for partial/narrow storage from its creation onset. This should make the work of extensions and other code modifying creation logic a bit simpler, as it provides a natural mechanism to pass metadata into repository creation. .. api:: options can now be passed to influence repository creation The various instance() functions to spawn new peers or repository instances now receive a ``createopts`` argument that can be a dict defining additional options to influence repository creation. localrepo.newreporequirements() also receives this argument.
e58d078bed5df90a6f7a9f62f00b58b7f5474cd9: localrepo: move repo creation logic out of localrepository.__init__ draft obsolete
Gregory Szorc <gregory.szorc@gmail.com> - Fri, 07 Sep 2018 16:33:47 -0700 - rev 49373
Push 909 by gszorc@mozilla.com at Sat, 08 Sep 2018 01:41:49 +0000
localrepo: move repo creation logic out of localrepository.__init__ It has long bothered me that local repository creation is handled as part of localrepository.__init__. Upcoming changes I want to make around how repositories are initialized and instantiated will make the continued existence of repository creation code in localrepository.__init__ even more awkward. localrepository instances are almost never constructed directly: instead, callers are supposed to go through hg.repository() to obtain a handle on a repository. And hg.repository() calls localrepo.instance() to return a new repo instance. This commit teaches localrepo.instance() to handle the create=True logic. Most of the code for repo construction has been moved to a standalone function. This allows extensions to monkeypatch the function to further customize freshly-created repositories. A few calls to localrepo.localrepository.__init__ that were passing create=True were converted to call localrepo.instance(). .. api:: local repo creation moved out of constructor ``localrepo.localrepository.__init__`` no longer accepts a ``create`` argument to create a new repository. New repository creation is now performed as part of ``localrepo.instance()`` and the bulk of the work is performed by ``localrepo.createrepository()``.
309676131dfac07bda816b519dd830b01d267b48: localrepo: pass ui to newreporequirements() draft obsolete
Gregory Szorc <gregory.szorc@gmail.com> - Fri, 07 Sep 2018 15:57:55 -0700 - rev 49372
Push 909 by gszorc@mozilla.com at Sat, 08 Sep 2018 01:41:49 +0000
localrepo: pass ui to newreporequirements() newreporequirements() is called as part of creating a new repository. It doesn't make much sense for it to receive a repo instance as part of determining what requirements for new repos should be. .. api:: localrepo.newreporequirements() receives a ui instead of a repo
a60dae060bc83e773bdbafb2432bc4cf387ebce2: ancestors: ensure a consistent order even in the "inclusive" case
Boris Feld <boris.feld@octobus.net> - Thu, 06 Sep 2018 19:37:38 -0400 - rev 49371
Push 909 by gszorc@mozilla.com at Sat, 08 Sep 2018 01:41:49 +0000
ancestors: ensure a consistent order even in the "inclusive" case It seems odds to first issue the "source" revs and then the other ancestors. In addition, doing so can break the other contract of always issuing a child before its parent. We update the code to apply the same logic to all yielded revision. No tests break so we seem in the clear except where we explicitly test the order.
(0) -30000 -10000 -300 -20 tip