Tue, 23 Oct 2018 16:24:04 +0300 narrow: rework logic to check whether we need to widen and narrow
Pulkit Goyal <pulkit@yandex-team.ru> [Tue, 23 Oct 2018 16:24:04 +0300] rev 40436
narrow: rework logic to check whether we need to widen and narrow This patch reworks logic which calculates whether we need to extend or narrow our working copy or not. We filter the addincludes, removeincludes, addexcludes and removeexcludes passed from user to the actual added and removed includes and excludes. What that means is a user can pass an already included path as addincludes, a path which is not included as removeincludes etc. In such situations the old logic use to think we need to do some work, whereas we don't need to do that work. In old logic, even if we don't have anything new to include but it believes we need to call widen, this adds some good amount of work on large repository. A widen calls involves computing incomming csets, calling the narrow_widen() which in non-ellipses cases goes through all the set of csets which are available which can take ~2-3 mins on large repos. Those 2-3 minutes are spend on doing nothing which a client can prevent by checking is there really anything which needs to be included. The tests changes shows that we don't go to the server anymore in such cases which is nice. Differential Revision: https://phab.mercurial-scm.org/D5183
Tue, 23 Oct 2018 14:26:17 +0300 tests: show that adding an already included path still calls narrow_widen()
Pulkit Goyal <pulkit@yandex-team.ru> [Tue, 23 Oct 2018 14:26:17 +0300] rev 40435
tests: show that adding an already included path still calls narrow_widen() This patch adds tests demonstrating that we still go to the server in non-ellipses widening when we have that path already on the client and there is nothing new to download. The next patch will try to make client side logic smart and not go to the server if we don't need to download anything. Differential Revision: https://phab.mercurial-scm.org/D5182
Sun, 14 Oct 2018 17:08:18 +0200 graft: introduce --base option for using custom base revision while merging
Mads Kiilerich <mads@kiilerich.com> [Sun, 14 Oct 2018 17:08:18 +0200] rev 40434
graft: introduce --base option for using custom base revision while merging The graft command usually performs an internal merge of the current parent revision with the graft revision, using p1 of the grafted revision as base for the merge. As a trivial extension of this, we introduce the --base option to allow for using another base revision. This can be used as a building block for grafting and collapsing multiple changesets at once, or for grafting the resulting change from a merge as a single simple change. (This is kind of similar to backout --parent ... only different: this graft base must be an ancestor, but is usually *not* a parent.) This is probably an advanced use case, and we do thus not show it in the non-verbose help.
Thu, 18 Oct 2018 12:31:06 +0200 changegroup: add a option to create bundle with full snapshot only
Boris Feld <boris.feld@octobus.net> [Thu, 18 Oct 2018 12:31:06 +0200] rev 40433
changegroup: add a option to create bundle with full snapshot only This is easy to implement now and can be useful for benchmarking.
Wed, 10 Oct 2018 00:21:02 +0200 changegroup: allow to force delta to be against p1
Boris Feld <boris.feld@octobus.net> [Wed, 10 Oct 2018 00:21:02 +0200] rev 40432
changegroup: allow to force delta to be against p1 This new developer option is useful to general more "generic" bundle. Without this option, a bundle generated from the repository use deltas similar to the one stored in the specific repository it was generated from. This makes performance testing a bit tricky. Using deltas similar to the final result means all delta stored in the bundle can be applied to the target repository without any further processing (except for the rare case of a full snapshot). The application of such bundles (almost) never exercises the (slower) path of searching for a new valid delta. This result in unrealistic and too favorable timing and profile. Instead, we introduce an option to make sure all revisions are stored as a delta against p1. It might not be the best generation option, but it guarantees that the content will be "generic", not favoring a specific target.
Wed, 31 Oct 2018 21:16:54 +0900 fix: disable use of thread-based worker stable
Yuya Nishihara <yuya@tcha.org> [Wed, 31 Oct 2018 21:16:54 +0900] rev 40431
fix: disable use of thread-based worker getfixes() accesses to repo, changectx, filectx, etc., so I believe there are code paths triggering data race. Mercurial API isn't thread safe in general.
Tue, 09 Oct 2018 23:26:35 +0200 storage: also use `deltamode argument` for ifiledata
Boris Feld <boris.feld@octobus.net> [Tue, 09 Oct 2018 23:26:35 +0200] rev 40430
storage: also use `deltamode argument` for ifiledata Now that lower level uses such argument, we can propagate the change to higher layers.
Wed, 31 Oct 2018 15:27:06 +0300 configitems: rename the config to prevent adding an alias in future stable
Pulkit Goyal <pulkit@yandex-team.ru> [Wed, 31 Oct 2018 15:27:06 +0300] rev 40429
configitems: rename the config to prevent adding an alias in future Right now the config option looks like: [experimental.server] stream-narrow-clones= which does not match how config options are generally defined in core. So let's rename this to: [experimental] server.stream-narrow-clones= before the new release so that we don't have to add an alias in future for this. Differential Revision: https://phab.mercurial-scm.org/D5198
Wed, 31 Oct 2018 11:02:08 +0100 sparse-revlog: only refine delta candidates in the sparse case (issue6006) stable
Boris Feld <boris.feld@octobus.net> [Wed, 31 Oct 2018 11:02:08 +0100] rev 40428
sparse-revlog: only refine delta candidates in the sparse case (issue6006) Starting with 5aef5afa8654, a valid delta parent might be "refined". This allows repository using sparse-revlog to produce better delta chain by using better intermediate snapshot base. However, this refining step was performed in all cases, including for repository not using sparse-revlog. This could produce a strange chain in the general delta case and corrupted repository in the non-general delta case. We now skip this step unless sparse-revlog is in use. In issue 6006, Yuya Nishihara provided a test case using an external repository, so we did not include it. Finding "laboratory" condition to reproduce this case and implementing an efficient test reproducing it is a bit tricky. We do not foresee to have the time to provide one by the release date. Differential Revision: https://phab.mercurial-scm.org/D5197
Tue, 09 Oct 2018 22:02:01 +0200 changegroup: refactor emitrevision to use a `deltamode` argument
Boris Feld <boris.feld@octobus.net> [Tue, 09 Oct 2018 22:02:01 +0200] rev 40427
changegroup: refactor emitrevision to use a `deltamode` argument This new argument gathers the semantic of `sendfulltext` and `deltaprevious` in a single value. We are about to introduce a new type of constraints. Avoiding yet another argument sounds like a plus.
Mon, 29 Oct 2018 16:23:42 -0400 http: work around custom http client classes that refuse extra attrs stable
Augie Fackler <augie@google.com> [Mon, 29 Oct 2018 16:23:42 -0400] rev 40426
http: work around custom http client classes that refuse extra attrs I have no idea what is going on with our custom http client code at Google, but it chokes on these extra attributes we're tucking on http clients. Since it feels more than a little wrong to just stuff extra data on a client, let's degrade gracefully when the client class refuses the attributes.
Tue, 23 Oct 2018 21:11:13 +0900 branchmap: do not specify changelog as an argument
Yuya Nishihara <yuya@tcha.org> [Tue, 23 Oct 2018 21:11:13 +0900] rev 40425
branchmap: do not specify changelog as an argument Since (unfiltered)repo.changelog lookup gets as fast as __dict__ lookup, there's no point to pass in changelog instance. $ hg perfbranchmap --clear-revbranch -R mozilla-central ! base (orig) wall 20.593091 comb 20.600000 user 20.520000 sys 0.080000 (best of 3) (this) wall 20.129126 comb 20.130000 user 20.020000 sys 0.110000 (best of 3) This backs out most of the changes in 76d4272bd57b and 47c03042cd1d.
Sat, 20 Oct 2018 17:56:00 +0900 filecache: unimplement __set__() and __delete__() (API)
Yuya Nishihara <yuya@tcha.org> [Sat, 20 Oct 2018 17:56:00 +0900] rev 40424
filecache: unimplement __set__() and __delete__() (API) Implementing __set__() implies that the descriptor can't be overridden by obj.__dict__, which means any property access involves slow function call. "Data descriptors with __set__() and __get__() defined always override a redefinition in an instance dictionary. In contrast, non-data descriptors can be overridden by instances." https://docs.python.org/2.7/reference/datamodel.html#invoking-descriptors This patch basically backs out 236bb604dc39, "scmutil: update cached copy when filecached attribute is assigned (issue3263)." The problem described in issue3263 (which is #3264 in Bugzilla) should no longer happen since repo._bookmarkcurrent has been moved to repo._bookmarks.active. We still have a risk of introducing similar bugs, but I think that's the cost we have to pay. $ hg perfrevset 'branch(tip)' -R mercurial (orig) wall 0.139511 comb 0.140000 user 0.140000 sys 0.000000 (best of 66) (prev) wall 0.114195 comb 0.110000 user 0.110000 sys 0.000000 (best of 81) (this) wall 0.099038 comb 0.110000 user 0.100000 sys 0.010000 (best of 93)
Sat, 20 Oct 2018 19:13:05 +0900 filecache: use try-except for faster __dict__ lookup
Yuya Nishihara <yuya@tcha.org> [Sat, 20 Oct 2018 19:13:05 +0900] rev 40423
filecache: use try-except for faster __dict__ lookup Python function call is slow, and the cost could be significant here. $ hg perfrevset 'branch(tip)' -R mercurial (orig) wall 0.139511 comb 0.140000 user 0.140000 sys 0.000000 (best of 66) (this) wall 0.114195 comb 0.110000 user 0.110000 sys 0.000000 (best of 81)
Thu, 25 Oct 2018 21:33:43 +0800 crecord: make nextsametype() check that parent item exists (issue6009) stable
Anton Shestakov <av6@dwimlabs.net> [Thu, 25 Oct 2018 21:33:43 +0800] rev 40422
crecord: make nextsametype() check that parent item exists (issue6009) Items that represent files in curses interface don't have parents.
Wed, 24 Oct 2018 10:05:13 -0400 help: describe what ui.tweakdefaults changes, concretely stable
Valentin Gatien-Baron <vgatien-baron@janestreet.com> [Wed, 24 Oct 2018 10:05:13 -0400] rev 40421
help: describe what ui.tweakdefaults changes, concretely Currently, one has to look at the code. A couple things are suboptimal: - probably not translatable - lines don't get wrapped (a couple are a bit too long) but it seems to better this way than without help at all. Differential Revision: https://phab.mercurial-scm.org/D5187
Thu, 25 Oct 2018 00:22:42 -0400 logexchange: convert paths to unix when detecting the active path stable
Matt Harbison <matt_harbison@yahoo.com> [Thu, 25 Oct 2018 00:22:42 -0400] rev 40420
logexchange: convert paths to unix when detecting the active path This fixes the problem in the tests[1] where Windows was showing the whole path as the remotename for local repositories. Somebody with a better understanding of this extension should probably take a deeper look. There may be other cases that need to be converted- specifically the `elif not instance` and the missing `else` cases in activepath(). I also noticed when adding debug prints that the absolute path is stored in the file, probably not normalized. (It's wrapped up in $TESTTMP.) [1] https://buildbot.mercurial-scm.org/builders/Win7%20x86_64%20hg%20tests/builds/1042/steps/run-tests.py%20%28python%202.7.13%29/logs/stdio
Wed, 24 Oct 2018 22:40:48 -0400 help: update the default value specified for `profiling.time-track` stable
Matt Harbison <matt_harbison@yahoo.com> [Wed, 24 Oct 2018 22:40:48 -0400] rev 40419
help: update the default value specified for `profiling.time-track` I tried conditionalizing this in a `.. container::` block, but that seemed to add an extra blank line between the main text and the parenthetical.
Wed, 24 Oct 2018 22:24:10 -0400 profiling: revert the default mode back to 'cpu' on Windows stable
Matt Harbison <matt_harbison@yahoo.com> [Wed, 24 Oct 2018 22:24:10 -0400] rev 40418
profiling: revert the default mode back to 'cpu' on Windows On Windows, os.times() only returns user and system times. Real elapsed time is 0. That results in no actual times reported, an end wall time of 0.000000, and seemingly randomly sorted stack frames. This at least provides test stability in test-profile.t. I kind of think that `default=pycompat.iswindows and 'cpu' or 'real'` would be a better way to set the default in configitems, but I didn't see any other examples of this, and thought maybe there's a reason for that. That might allow plugging the value into the help text automatically- the documented default wasn't updated in db0dba2d157d.
Wed, 17 Oct 2018 14:47:01 +0200 phase: add an archived phase stable
Boris Feld <boris.feld@octobus.net> [Wed, 17 Oct 2018 14:47:01 +0200] rev 40417
phase: add an archived phase This phase allows for hidden changesets in the "user space". It differs from the "internal" phase which is intended for internal by-product only. There have been discussions at the 4.8 sprint to use such phase to speedup cleanup after history rewriting operation. Shipping it in the same release as the 'internal-phase' groups the associated `requires` entry. The important bit is to have support for this phase in the earliest version of mercurial possible. Adding the UI to manipulate this new phase later seems fine. The current plan for archived usage and user interface are as follow. On a repository with internal-phase on and evolution off: * history rewriting command set rewritten changeset in the archived phase. (This mean updating the cleanupnodes method). * keep `hg unbundle .hg/strip-backup/X.hg` as a way to restore changeset for now (backup bundle need to contains phase data) * [maybe] add a `hg strip --soft` advance flag (a light way to expose the feature without getting in the way of a better UI) Mercurial 4.8 freeze is too close to get the above in by then. We don't introduce a new repository `requirement` as we reuse the one introduced with the 'archived' phase during the 4.8 cycle.
Tue, 23 Oct 2018 20:46:21 +0900 exewrapper: apply clang-format to silence test-check-clang-format.t stable
Yuya Nishihara <yuya@tcha.org> [Tue, 23 Oct 2018 20:46:21 +0900] rev 40416
exewrapper: apply clang-format to silence test-check-clang-format.t
Thu, 18 Oct 2018 19:57:30 -0700 help: displaying extension commands by default
rdamazio@google.com [Thu, 18 Oct 2018 19:57:30 -0700] rev 40415
help: displaying extension commands by default Differential Revision: https://phab.mercurial-scm.org/D5156
Thu, 18 Oct 2018 19:57:05 -0700 help: displaying documented aliases by default
rdamazio@google.com [Thu, 18 Oct 2018 19:57:05 -0700] rev 40414
help: displaying documented aliases by default This makes aliases be displayed in "hg help" when they have a :doc config entry, and also allows them to be assigned to a category with :category. Differential Revision: https://phab.mercurial-scm.org/D5087
Sat, 13 Oct 2018 05:43:39 -0700 help: allow hiding of help topics
rdamazio@google.com [Sat, 13 Oct 2018 05:43:39 -0700] rev 40413
help: allow hiding of help topics Differential Revision: https://phab.mercurial-scm.org/D5077
Sat, 13 Oct 2018 05:02:55 -0700 help: allow commands to be hidden
rdamazio@google.com [Sat, 13 Oct 2018 05:02:55 -0700] rev 40412
help: allow commands to be hidden This is useful in enterprise environments where some workflows are discouraged. Differential Revision: https://phab.mercurial-scm.org/D5076
Sat, 20 Oct 2018 00:12:20 +0300 py3: add one more passing test to whitelist
Pulkit Goyal <pulkit@yandex-team.ru> [Sat, 20 Oct 2018 00:12:20 +0300] rev 40411
py3: add one more passing test to whitelist Caught by python 3 builder. Differential Revision: https://phab.mercurial-scm.org/D5175
Sat, 20 Oct 2018 00:05:50 +0300 py3: make sure we pass sysstr in sqlite3.connect()
Pulkit Goyal <pulkit@yandex-team.ru> [Sat, 20 Oct 2018 00:05:50 +0300] rev 40410
py3: make sure we pass sysstr in sqlite3.connect() Differential Revision: https://phab.mercurial-scm.org/D5174
Tue, 05 Sep 2017 15:24:25 -0700 archive: use manifest.matches() to simplify and speed up matching
Martin von Zweigbergk <martinvonz@google.com> [Tue, 05 Sep 2017 15:24:25 -0700] rev 40409
archive: use manifest.matches() to simplify and speed up matching manifest.matches() can avoid walking paths the user did not want to archive. Differential Revision: https://phab.mercurial-scm.org/D5178
Tue, 05 Sep 2017 15:24:22 -0700 archive: create alwaysmatcher when no matcher provided
Martin von Zweigbergk <martinvonz@google.com> [Tue, 05 Sep 2017 15:24:22 -0700] rev 40408
archive: create alwaysmatcher when no matcher provided Differential Revision: https://phab.mercurial-scm.org/D5177
Tue, 05 Sep 2017 15:21:21 -0700 archive: change "matcnfn" argument to a real matcher
Martin von Zweigbergk <martinvonz@google.com> [Tue, 05 Sep 2017 15:21:21 -0700] rev 40407
archive: change "matcnfn" argument to a real matcher All callers seem to be passing a real matcher, not just a function. We were also passing it into match.subdirmatcher(), which assumes it is a matcher. Differential Revision: https://phab.mercurial-scm.org/D5176
Mon, 22 Oct 2018 14:48:14 -0400 Added signature for changeset 956ec6f1320d stable
Augie Fackler <raf@durin42.com> [Mon, 22 Oct 2018 14:48:14 -0400] rev 40406
Added signature for changeset 956ec6f1320d
Mon, 22 Oct 2018 14:48:11 -0400 Added tag 4.8rc0 for changeset 956ec6f1320d stable
Augie Fackler <raf@durin42.com> [Mon, 22 Oct 2018 14:48:11 -0400] rev 40405
Added tag 4.8rc0 for changeset 956ec6f1320d
Mon, 22 Oct 2018 14:46:06 -0400 merge to stable for 4.8 release freeze stable 4.8rc0
Augie Fackler <augie@google.com> [Mon, 22 Oct 2018 14:46:06 -0400] rev 40404
merge to stable for 4.8 release freeze
Mon, 22 Oct 2018 11:34:35 -0700 shortest: never emit 0-length prefix even if unique
Martin von Zweigbergk <martinvonz@google.com> [Mon, 22 Oct 2018 11:34:35 -0700] rev 40403
shortest: never emit 0-length prefix even if unique It turned out that the pure version of our code for finding the shortest unique nodeid prefix would return a 0-length string if that was unique (because there was at most one revision in the disambiguation set). That's kind of correct, but it can't be used as input, so we shouldn't return it. Let's just adjust the given minlength up to at least 1. This fixes test-template-functions.t, which was failing in pure mode. Differential Revision: https://phab.mercurial-scm.org/D5181
Mon, 22 Oct 2018 15:51:01 +0200 logtoprocess: sends the canonical command name to the subprocess
Boris Feld <boris.feld@octobus.net> [Mon, 22 Oct 2018 15:51:01 +0200] rev 40402
logtoprocess: sends the canonical command name to the subprocess One of the use-case of logtoprocess is to monitor command duration. With the current code, we only get whatever command name the user typed (either abbreviated or aliased). This makes analytics on the collected data more difficult. Stores the canonical command name in the request object. Pass the stored canonical name in the `req.ui.log("commandfinish", ...)` call as keyword argument to not break potential string formatting. Pass the value as the environment variable named `LTP_COMMAND` to the called script. Differential Revision: https://phab.mercurial-scm.org/D4820
Mon, 22 Oct 2018 15:47:30 +0200 logtoprocess: fix message formatting
Boris Feld <boris.feld@octobus.net> [Mon, 22 Oct 2018 15:47:30 +0200] rev 40401
logtoprocess: fix message formatting The logtoprocess used to try formatting the message using keyword options instead of always using the rest of the arguments. Update it to match blackbox behavior. Differential Revision: https://phab.mercurial-scm.org/D5180
Sat, 18 Aug 2018 01:44:38 +0200 profiling: move default mode to "real" time
Boris Feld <boris.feld@octobus.net> [Sat, 18 Aug 2018 01:44:38 +0200] rev 40400
profiling: move default mode to "real" time Mercurial operations involve a lot of disks or network access. These impact command runtime significantly and it seems important to report them in our default profiling output. Having the right default means that we don't forget them when asking people to produces profiling traces or when doing profiling ourselves. Moving to "real time" by default will remove the need to think about activating it on most occasions. The "CPU" time-based profiling is still accessible when necessary.
Fri, 05 Oct 2018 23:40:12 +0800 streamclone: abort when client needs to handle obsmarkers, but doesn't
Anton Shestakov <av6@dwimlabs.net> [Fri, 05 Oct 2018 23:40:12 +0800] rev 40399
streamclone: abort when client needs to handle obsmarkers, but doesn't When client doesn't have any of obsolescence markers exchange capabilities, then it's safe to say it can't handle obsmarkers. However, if it understands even one format version, then stream clones are fine -- client can use "obsmarkers" bundle2 part.
Fri, 05 Oct 2018 23:27:17 +0800 streamclone: include obsstore file into stream bundle if client can read it
Anton Shestakov <av6@dwimlabs.net> [Fri, 05 Oct 2018 23:27:17 +0800] rev 40398
streamclone: include obsstore file into stream bundle if client can read it
Fri, 19 Oct 2018 18:34:42 -0400 setup: build exewrapper with Unicode support on py3
Matt Harbison <matt_harbison@yahoo.com> [Fri, 19 Oct 2018 18:34:42 -0400] rev 40397
setup: build exewrapper with Unicode support on py3 I didn't see a compiler switch documented anywhere, but I diffed the command line for full VC++ project when toggling between MBCS and Unicode. This is all they do.
Fri, 19 Oct 2018 18:32:13 -0400 exewrapper: convert to _tcsxxx functions for Unicode compatability
Matt Harbison <matt_harbison@yahoo.com> [Fri, 19 Oct 2018 18:32:13 -0400] rev 40396
exewrapper: convert to _tcsxxx functions for Unicode compatability This fixes more than 50 tests on py3 on Windows when enabled, mostly hooks and such that invoked `hg` directly. 187 left to go. I skipped doing the abort printing with Unicode because of apparent issues with MinGW [1]. It may be moot though, as MinGW isn't listed as a supported compiler after 3.4 [2]. [1] https://stackoverflow.com/questions/17700797/printf-wprintf-s-s-ls-char-and-wchar-errors-not-announced-by-a-compil [2] https://wiki.python.org/moin/WindowsCompilers
Fri, 19 Oct 2018 18:23:14 -0400 exewrapper: drop an unused variable
Matt Harbison <matt_harbison@yahoo.com> [Fri, 19 Oct 2018 18:23:14 -0400] rev 40395
exewrapper: drop an unused variable
Thu, 18 Oct 2018 21:14:22 +0900 commands: restore compatibility for "^cmd" registration (issue6005)
Yuya Nishihara <yuya@tcha.org> [Thu, 18 Oct 2018 21:14:22 +0900] rev 40394
commands: restore compatibility for "^cmd" registration (issue6005) This is done at loading time, where ui is available.
Fri, 19 Oct 2018 12:30:49 +0200 exchangev2: support fetching shallow files history
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 19 Oct 2018 12:30:49 +0200] rev 40393
exchangev2: support fetching shallow files history This commit teaches the exchangev2 client code to handle fetching shallow files data. Only shallow fetching of files data is supported: shallow fetching of changeset and manifest data is explicitly not yet supported. Previously, we would fetch file revisions for changesets that were received by the current pull operation. In the new model, we calculate the set of "relevant" changesets given the pull depth and only fetch files data for those changesets. We also teach the "filesdata" command invocation to vary parameters as needed. The implementation here is far from complete or optimal. Subsequent pulls will end up re-fetching a lot of files data. But the application of this data should mostly be a no-op on the client, so it isn't a big deal. Depending on the order file revisions are fetched in, revisions could get inserted with the wrong revision number relationships. I think the best way to deal with this is to remove revision numbers from storage and to either dynamically derive them (by reconstructing a DAG from nodes/parents) or remove revision numbers from the file storage interface completely. A missing API that we'll likely want to write pretty soon is "ensure files for revision(s) are present." We can kind of cajole exchangev2.pull() to do this. But it isn't very efficient. For example, in simple cases like widening the store to obtain data for a single revision, it is probably more efficient to walk the manifest and find exactly which file revisions are missing and to make explicit requests for just their data. In more advanced cases, asking the server for all files data may be more efficient, even though it requires sending data the client already has. There is tons of room for future experimentation here. And TBH I'm not sure what the final state will be. Anyway, this commit gets us pretty close to being able to have shallow and narrow checkouts with exchangev2/sqlite storage. Close enough that a minimal extension should be able to provide fill in the gaps until the code in core stabilizes and there is a user-facing way to trigger the narrow/shallow bits from `hg clone` without also implying using of the narrow extension... Differential Revision: https://phab.mercurial-scm.org/D5169
Wed, 17 Oct 2018 17:32:15 +0200 sqlitestore: support for storing revisions without their parents
Gregory Szorc <gregory.szorc@gmail.com> [Wed, 17 Oct 2018 17:32:15 +0200] rev 40392
sqlitestore: support for storing revisions without their parents This commit kinda/sorta implements the equivalent of ellipsis nodes for the SQLite storage backend. Without implementing full blown ellipsis nodes (and the necessary support for them in the wire protocol), we instead teach the store to rewrite the p1 and p2 nodes to nullid when the incoming parent isn't in the local store. This allows servers to remain dumb and send the real parent and have the clients deal with the missing parent problem. This obviously isn't ideal because a benefit of ellipsis nodes is we can insert a fake parent to ellide missing changesets. But neither solution is ideal because it drops the original parent from storage. We could probably teach the SQLite store to retain the original parent and handle missing parents at read time. However, parent revisions are stored as integers and it isn't trivial to store an "empty" revision in the store yet, which would be necessary to represent the "missing" parent. The store is somewhat intelligent in trying to remove the missing parents metadata when the revision is re-added. But, revision numbers will be all messed up in that case, so I'm not sure it is worth it. At some point we'll likely want to remove the concept of revision numbers from the database and have the store invent them at index generation time. Or even better, we can do away with revision numbers from the file storage interface completely. We'll get there eventually... Differential Revision: https://phab.mercurial-scm.org/D5168
Fri, 19 Oct 2018 15:38:25 +0200 wireprotov2: support exposing linknode of file revisions
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 19 Oct 2018 15:38:25 +0200] rev 40391
wireprotov2: support exposing linknode of file revisions When supporting shallow file storage, clients may fetch file revisions by changeset. But they may not readily know which changeset introduced a specific file revision. The "linknode" is used to record which changeset introduces which file revision. This commit teaches the "filedata" and "filesdata" wire protocol commands to expose the linknode for file revisions. The implementation is likely wrong when hidden changesets are in play, since the linknode may refer to a hidden changeset. We can deal with this problem later. Differential Revision: https://phab.mercurial-scm.org/D5167
Fri, 19 Oct 2018 14:59:03 +0200 localrepo: support marking repos as having shallow file storage
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 19 Oct 2018 14:59:03 +0200] rev 40390
localrepo: support marking repos as having shallow file storage Various operations against repositories need to know if repository storage is full or partial. For example, a checkout (including possibly a widening of a sparse checkout), needs to know if it can assume all file revisions are available or whether to look for missing revisions first. This commit lays the plumbing for doing that. We define a repo creation option that indicates that shallow file storage is desired. The SQLite store uses this creation option to add an extra repo requirement indicating file storage is shallow. A new repository feature has been added to indicate that file storage is shallow. The SQLite store adds this feature when the shallow file store requirement is present. Code can now look at repo.features to determine if repo file storage may be shallow and take additional actions if so. While we're here, we also teach the SQLite store to handle the narrow repo requirement, which gets added when making narrow clones. Differential Revision: https://phab.mercurial-scm.org/D5166
Wed, 26 Sep 2018 14:41:15 -0700 repository: teach addgroup() to receive data with missing parents
Gregory Szorc <gregory.szorc@gmail.com> [Wed, 26 Sep 2018 14:41:15 -0700] rev 40389
repository: teach addgroup() to receive data with missing parents The way the narrow extension works today, the server rewrites outgoing changegroup data to lie about parents when the parents data is missing. It adds the ellipsis flag to the revision so it can be recorded as such in the revlog. In the new wire protocol, such rewriting does not occur on the server (at least not yet anyway). Instead, it is up to the client to recognize when it has received a revision without its parents. This means rewriting will be performed on the client. Furthermore, the mechanism for storing a shallow revision may differ from store to store. For example, the revlog store uses the ellipsis flag to denote a revision's parents have been rewritten. But a non-revlog store may wish to store things differently. And, some stores may not even support receiving shallow revision data! Therefore, it makes sense for the store itself to be making decisions about what to do when they receive revision data without their parents. This commit teaches the addgroup() bulk insert method to accept a boolean argument that indicates whether the incoming data may lack parent revisions. This flag can be set when receiving "shallow" data from a remote. The revlog implementation of this method has been taught to rewrite the missing parent(s) to nullid and to add the ellipsis flag to the revision when a missing parent is encountered. But it only does this if ellipsis flags are enabled on the repo and the incoming data is marked as possibly shallow. An error occurs otherwise. Differential Revision: https://phab.mercurial-scm.org/D5165
Fri, 19 Oct 2018 13:44:25 +0200 commands: support passing depth to hg.clone()
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 19 Oct 2018 13:44:25 +0200] rev 40388
commands: support passing depth to hg.clone() This will allow extensions to add --depth or other arguments to control depth fetching. Differential Revision: https://phab.mercurial-scm.org/D5164
Wed, 03 Oct 2018 14:57:29 -0700 filelog: add a hasnode() method (API)
Gregory Szorc <gregory.szorc@gmail.com> [Wed, 03 Oct 2018 14:57:29 -0700] rev 40387
filelog: add a hasnode() method (API) Missing in the file storage interface is the ability to query whether a specified value is a known node. This commit defines that interface member and implements it on the revlog and sqlite file stores. Storage unit tests have been added. The revlog implementation is a bit more complicated because index lookups don't consistently raise the same exception. For SQLite, we can simply look for a key in a dict. Differential Revision: https://phab.mercurial-scm.org/D5163
Sun, 21 Oct 2018 22:26:00 -0400 lfs: consult the narrow matcher when extracting pointers from ctx (issue5794)
Matt Harbison <matt_harbison@yahoo.com> [Sun, 21 Oct 2018 22:26:00 -0400] rev 40386
lfs: consult the narrow matcher when extracting pointers from ctx (issue5794) I added a testcase for lfs to all narrow tests, and the following failed: test-narrow-acl.t test-narrow-exchange.t test-narrow-patterns.t test-narrow-strip.t test-narrow-trackedcmd.t test-narrow-widen.t test-narrow.t The first two still have errors in the pretxnchangegroup on clone and (receiving a) push, which I'm still looking into (4d63f3bc1e1a fixed something in this area already). These two modified tests seem to cover the things that failed in the remaining narrow tests, i.e. `hg tracked` and `hg strip`, so I didn't bother enabling the testcases elsewhere. Maybe we should, but it's 68 tests total.
Sat, 20 Oct 2018 20:25:56 +0900 statprof: fix overflow while skipping boilerplate parts
Yuya Nishihara <yuya@tcha.org> [Sat, 20 Oct 2018 20:25:56 +0900] rev 40385
statprof: fix overflow while skipping boilerplate parts I got IndexError randomly because of stack[i] where i = len(stack).
Sat, 20 Oct 2018 20:15:48 +0900 statprof: fix indent level of fp.write() (issue6004)
Yuya Nishihara <yuya@tcha.org> [Sat, 20 Oct 2018 20:15:48 +0900] rev 40384
statprof: fix indent level of fp.write() (issue6004) It was changed at 9d3034348c4f by mistake.
Fri, 19 Oct 2018 22:31:47 -0400 py3: stringify setupversion on Windows
Matt Harbison <matt_harbison@yahoo.com> [Fri, 19 Oct 2018 22:31:47 -0400] rev 40383
py3: stringify setupversion on Windows This was stringified a few lines above for non Windows platforms, but `version` remains bytes. The old code effectively undid the conversion, and triggered a warning in setuptools when building.
Fri, 19 Oct 2018 23:47:38 -0400 tests: add coverage for some untested areas of hgweb
Matt Harbison <matt_harbison@yahoo.com> [Fri, 19 Oct 2018 23:47:38 -0400] rev 40382
tests: add coverage for some untested areas of hgweb The fact that these mimetype guesses weren't blowing up anywhere on py3 prior to 9310037f0636 was the giveaway. The annotate function is a bit unusual in that it renders the page with a 500 in the middle, so I left the HTML output. For the other functions, checking the access log is enough.
Fri, 19 Oct 2018 23:30:56 +0300 statprof: update the name as the i increases (issue6003)
Pulkit Goyal <pulkit@yandex-team.ru> [Fri, 19 Oct 2018 23:30:56 +0300] rev 40381
statprof: update the name as the i increases (issue6003) 2864f8d3fcd6 while working on py3 fix, take out the name building out of the loop so we were not building the new stack-name for each i, rather we were using the first one again and again. The test changes shows the profile is now working. Differential Revision: https://phab.mercurial-scm.org/D5172
Fri, 19 Oct 2018 23:18:29 +0300 test: show more profile lines in test-profile.t
Pulkit Goyal <pulkit@yandex-team.ru> [Fri, 19 Oct 2018 23:18:29 +0300] rev 40380
test: show more profile lines in test-profile.t This shows that we don't output anything after the first line and demonstrate issue6003. Differential Revision: https://phab.mercurial-scm.org/D5171
Fri, 19 Oct 2018 11:45:51 -0400 keepalive: use getattr to avoid AttributeErrors when vcr is in use
Augie Fackler <augie@google.com> [Fri, 19 Oct 2018 11:45:51 -0400] rev 40379
keepalive: use getattr to avoid AttributeErrors when vcr is in use Fixes test-phabricator.t. Differential Revision: https://phab.mercurial-scm.org/D5160
Fri, 19 Oct 2018 11:45:25 -0400 phabricator: do more of the VCR work in demandimport.deactivated()
Augie Fackler <augie@google.com> [Fri, 19 Oct 2018 11:45:25 -0400] rev 40378
phabricator: do more of the VCR work in demandimport.deactivated() If I don't do this, VCR gets confused looking for pycurl and other libraries. I have no idea how this ever worked. Differential Revision: https://phab.mercurial-scm.org/D5159
Fri, 19 Oct 2018 11:28:29 -0400 tests: sleep longer in test-logtoprocess.t
Augie Fackler <augie@google.com> [Fri, 19 Oct 2018 11:28:29 -0400] rev 40377
tests: sleep longer in test-logtoprocess.t We should probably write some sort of helper that can wait N seconds for all specified values to appear in a file or something, but for now this will fix the FreeBSD buildbot. Differential Revision: https://phab.mercurial-scm.org/D5157
(0) -30000 -10000 -3000 -1000 -300 -100 -60 +60 +100 +300 +1000 +3000 +10000 tip