Wed, 05 Feb 2020 17:13:51 -0500 manifest: move matches method to be outside the interface
Augie Fackler <augie@google.com> [Wed, 05 Feb 2020 17:13:51 -0500] rev 44352
manifest: move matches method to be outside the interface In order to adequately smoke out any legacy consumers of the method, we rename it to _matches so it's clear that it's class-private. To my amazement, all consumers of this method really only wanted matching filenames, not a full filtered manifest. Differential Revision: https://phab.mercurial-scm.org/D8085
Mon, 10 Feb 2020 21:02:22 -0500 tags: use modern // operator for division
Augie Fackler <augie@google.com> [Mon, 10 Feb 2020 21:02:22 -0500] rev 44351
tags: use modern // operator for division Fixes a test on Python 3. # skip-blame only correcting a division operator, not a substantive change Differential Revision: https://phab.mercurial-scm.org/D8108
Mon, 10 Feb 2020 20:47:19 -0500 tags: fix some type confusion exposed in python 3
Augie Fackler <augie@google.com> [Mon, 10 Feb 2020 20:47:19 -0500] rev 44350
tags: fix some type confusion exposed in python 3 # skip-blame just b-prefix and %-format cleanup, no meaningful change Differential Revision: https://phab.mercurial-scm.org/D8107
Fri, 10 Jan 2020 17:20:12 -0800 rebase: remove some now-unused parent arguments
Martin von Zweigbergk <martinvonz@google.com> [Fri, 10 Jan 2020 17:20:12 -0800] rev 44349
rebase: remove some now-unused parent arguments Differential Revision: https://phab.mercurial-scm.org/D7829
Fri, 10 Jan 2020 21:40:01 -0800 rebase: remove some redundant setting of dirstate parents
Martin von Zweigbergk <martinvonz@google.com> [Fri, 10 Jan 2020 21:40:01 -0800] rev 44348
rebase: remove some redundant setting of dirstate parents Since we're now setting the dirstate parents to its correct values from the beginning (right after `merge.update()`), we usually don't need to set them again before committing. The only case we need to care about is when committing collapsed commits. So we can remove the `setparents()` calls just before committing and add one only for the collapse case. Differential Revision: https://phab.mercurial-scm.org/D7828
Fri, 10 Jan 2020 14:22:20 -0800 rebase: don't use rebased node as dirstate p2 (BC)
Martin von Zweigbergk <martinvonz@google.com> [Fri, 10 Jan 2020 14:22:20 -0800] rev 44347
rebase: don't use rebased node as dirstate p2 (BC) When rebasing a node, we currently use the rebased node as p2 in the dirstate until just before we commit it (we then change to the desired parents). This p2 is visible to the user when the rebase gets interrupted because of merge conflicts. That can be useful to the user as a reminder of which commit is currently being rebased, but I believe it's incorrect for a few reasons: * I think the dirstate parents should be the ones that will be set when the commit is created. * I think having two parents means that you're merging those two commits, but when rebasing, you're generally grafting, not merging. * When rebasing a merge commit, we should use the two desired parents as dirstate parents (and we clearly can't have the rebased node as a third dirstate parent). * `hg graft` (and `hg update --merge`) sets only one parent and `hg rebase` should be consistent with that. I realize that this is a somewhat large user-visible change, but I think it's worth it because it will simplify things quite a bit. Differential Revision: https://phab.mercurial-scm.org/D7827
Fri, 10 Jan 2020 14:17:56 -0800 rebase: stop relying on having two parents to resume rebase
Martin von Zweigbergk <martinvonz@google.com> [Fri, 10 Jan 2020 14:17:56 -0800] rev 44346
rebase: stop relying on having two parents to resume rebase I'm about to make it so we don't have two parents when a rebase is interrupted (unless we're just rebasing on a merge commit). The code for detecting if we're resuming a rebase relied on having two parents, so this patch rewrites that to instead set a boolean when we resume. Note that `self.resume` in the new condition implies `not self.inmemory` (rebase cannot be resumed in memory), so that's why that part can be omitted. Differential Revision: https://phab.mercurial-scm.org/D7826
Tue, 28 Jan 2020 21:49:50 -0800 graphlog: use '%' for other context in merge conflict
Martin von Zweigbergk <martinvonz@google.com> [Tue, 28 Jan 2020 21:49:50 -0800] rev 44345
graphlog: use '%' for other context in merge conflict This lets the user more easily find the commit that is involved in the conflict, such as the source of `hg update -m` or the commit being grafted by `hg graft`. Differential Revision: https://phab.mercurial-scm.org/D8043
Wed, 29 Jan 2020 14:42:54 -0800 tests: add `hg log -G` output when there are merge conflicts
Martin von Zweigbergk <martinvonz@google.com> [Wed, 29 Jan 2020 14:42:54 -0800] rev 44344
tests: add `hg log -G` output when there are merge conflicts The next commit will change the behavior for these. I've used slightly different commands in the different tests to match the surrounding style. Differential Revision: https://phab.mercurial-scm.org/D8042
Wed, 29 Jan 2020 11:30:35 -0800 revset: add a revset for parents in merge state
Martin von Zweigbergk <martinvonz@google.com> [Wed, 29 Jan 2020 11:30:35 -0800] rev 44343
revset: add a revset for parents in merge state This may be particularly useful soon, when I'm going to change how `hg rebase` sets its parents during conflict resolution. Differential Revision: https://phab.mercurial-scm.org/D8041
Fri, 10 Jan 2020 17:46:10 -0800 tests: add test of rebase with conflict in merge commit
Martin von Zweigbergk <martinvonz@google.com> [Fri, 10 Jan 2020 17:46:10 -0800] rev 44342
tests: add test of rebase with conflict in merge commit It doesn't seem like we had any tests of this. I think it's pretty weird that the two parents we're merging are not the working copy parents during the conflict resolution. Differential Revision: https://phab.mercurial-scm.org/D7824
Thu, 16 Jan 2020 00:03:19 -0800 rebase: always be graft-like, not merge-like, also for merges
Martin von Zweigbergk <martinvonz@google.com> [Thu, 16 Jan 2020 00:03:19 -0800] rev 44341
rebase: always be graft-like, not merge-like, also for merges Rebase works by updating to a commit and then grafting changes on top. However, before this patch, it would actually merge in changes instead of grafting them in in some cases. That is, it would use the common ancestor as base instead of using one of the parents. That seems wrong to me, so I'm changing it so `defineparents()` always returns a value for `base`. This fixes the bad behavior in test-rebase-newancestor.t, which was introduced in 65f215ea3e8e (tests: add test for rebasing merges with ancestors of the rebase destination, 2014-11-30). The difference in test-rebase-dest.t is because the files in the tip revision were A, D, E, F before this patch and A, D, F, G after it. I think both files should ideally be there. Differential Revision: https://phab.mercurial-scm.org/D7907
Wed, 15 Jan 2020 15:51:01 +0100 nodemap: update the index with the newly written data (when appropriate)
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 15 Jan 2020 15:51:01 +0100] rev 44340
nodemap: update the index with the newly written data (when appropriate) If we are to use mmap to read the nodemap data, and if the python code is responsible for the IO, we need to refresh the mmap after each write and provide it back to the index. We start this dance without the mmap first. Differential Revision: https://phab.mercurial-scm.org/D7893
Wed, 15 Jan 2020 15:50:52 +0100 nodemap: never read more than the expected data amount
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 15 Jan 2020 15:50:52 +0100] rev 44339
nodemap: never read more than the expected data amount Since we are tracking this number we can use it to detect corrupted rawdata file and to only read the correct amount of data when possible. Differential Revision: https://phab.mercurial-scm.org/D7892
Wed, 15 Jan 2020 15:50:43 +0100 nodemap: write new data from the expected current data length
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 15 Jan 2020 15:50:43 +0100] rev 44338
nodemap: write new data from the expected current data length If the amount of data in the file exceed the expect amount, we will overwrite the extra data. This is a simple way to be safer. Differential Revision: https://phab.mercurial-scm.org/D7891
Wed, 15 Jan 2020 15:50:33 +0100 nodemap: double check the source docket when doing incremental update
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 15 Jan 2020 15:50:33 +0100] rev 44337
nodemap: double check the source docket when doing incremental update In theory, the index will have the information we expect it to have. However by security, it seems safer to double check that the incremental data are generated from the data currently on disk. Differential Revision: https://phab.mercurial-scm.org/D7890
Wed, 15 Jan 2020 15:50:24 +0100 nodemap: track the total and unused amount of data in the rawdata file
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 15 Jan 2020 15:50:24 +0100] rev 44336
nodemap: track the total and unused amount of data in the rawdata file We need to keep that information around: * total data will allow transaction to start appending new information without confusing other reader. * unused data will allow to detect when we should regenerate new rawdata file. Differential Revision: https://phab.mercurial-scm.org/D7889
Wed, 15 Jan 2020 15:50:14 +0100 nodemap: track the maximum revision tracked in the nodemap
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 15 Jan 2020 15:50:14 +0100] rev 44335
nodemap: track the maximum revision tracked in the nodemap We need a simple way to detect when the on disk data contains less revision than the index we read from disk. The docket file is meant for this, we just had to start tracking that data. We should also try to detect strip operation, but we will deal with this in later changesets. Right now we are focusing on defining the API for index supporting persistent nodemap. Differential Revision: https://phab.mercurial-scm.org/D7888
Wed, 15 Jan 2020 15:50:04 +0100 nodemap: add a flag to dump the details of the docket
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 15 Jan 2020 15:50:04 +0100] rev 44334
nodemap: add a flag to dump the details of the docket We are about to add more information to the docket. We first introduce a way to debug its content. Differential Revision: https://phab.mercurial-scm.org/D7887
Wed, 15 Jan 2020 15:49:54 +0100 nodemap: introduce append-only incremental update of the persistent data
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 15 Jan 2020 15:49:54 +0100] rev 44333
nodemap: introduce append-only incremental update of the persistent data Rewriting the full nodemap for each transaction has a cost we would like to avoid. We introduce a new way to write persistent nodemap data by adding new information at the end for file. Any new and updated block as added at the end of the file. The last block is the new root node. With this method, some of the block already on disk get "dereferenced" and become dead data. In later changesets, We'll start tracking the amount of dead data to eventually re-generate a full nodemap. Differential Revision: https://phab.mercurial-scm.org/D7886
Thu, 20 Feb 2020 16:21:00 -0800 shelve: fix ordering of merge labels stable
Kyle Lippincott <spectral@google.com> [Thu, 20 Feb 2020 16:21:00 -0800] rev 44332
shelve: fix ordering of merge labels Differential Revision: https://phab.mercurial-scm.org/D8140
Thu, 20 Feb 2020 17:06:01 -0800 shelve: add test clearly demonstrating that the conflict labels are backwards stable
Kyle Lippincott <spectral@google.com> [Thu, 20 Feb 2020 17:06:01 -0800] rev 44331
shelve: add test clearly demonstrating that the conflict labels are backwards Differential Revision: https://phab.mercurial-scm.org/D8139
Sun, 16 Feb 2020 17:05:18 -0500 import: don't ignore `--secret` when `--bypass` is specified stable
Matt Harbison <matt_harbison@yahoo.com> [Sun, 16 Feb 2020 17:05:18 -0500] rev 44330
import: don't ignore `--secret` when `--bypass` is specified Differential Revision: https://phab.mercurial-scm.org/D8126
Tue, 18 Feb 2020 13:46:10 -0500 phabricator: fix a phabsend crash when processing a renamed binary stable
Matt Harbison <matt_harbison@yahoo.com> [Tue, 18 Feb 2020 13:46:10 -0500] rev 44329
phabricator: fix a phabsend crash when processing a renamed binary This was a trivial fix, and some more tests are added to cover binary files. Since the old filecontext is passed in, the old name is still available. But I noticed some weirdness around what it marked as binary and not, and what is viewable in Phabricator. Those things have been flagged, and will probably take some digging. Differential Revision: https://phab.mercurial-scm.org/D8133
Fri, 13 Dec 2019 10:37:45 +0100 test: pin the number of CPU for issue4074 tests stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 13 Dec 2019 10:37:45 +0100] rev 44328
test: pin the number of CPU for issue4074 tests On machine with an hundreds of CPUs, the "user" CPU time reported can be inflated by the status steps. Since the test especially focus on the diff computation, we restrict the number of CPU to avoid potential issues. Differential Revision: https://phab.mercurial-scm.org/D8112
Wed, 12 Feb 2020 23:23:59 +0100 rust-dirstatemap: add `NonNormalEntries` class stable
Raphaël Gomès <rgomes@octobus.net> [Wed, 12 Feb 2020 23:23:59 +0100] rev 44327
rust-dirstatemap: add `NonNormalEntries` class This fix introduces the same encapsulation as the `copymap`. There is no easy way of doing this any better for now. `hg up -r null && time HGRCPATH= HGMODULEPOLICY=rust+c hg up tip` on Mozilla Central, (not super recent, but it doesn't matter): Before: 7:44,08 total After: 1:03,23 total Pretty brutal regression! This is a graft on stable of cf1f8660e568 Differential Revision: https://phab.mercurial-scm.org/D8111
Thu, 30 Jan 2020 14:57:02 +0100 rust-dirstatemap: cache non normal and other parent set stable
Raphaël Gomès <rgomes@octobus.net> [Thu, 30 Jan 2020 14:57:02 +0100] rev 44326
rust-dirstatemap: cache non normal and other parent set Performance of `hg update` was significantly worse since the introduction of the Rust `dirstatemap`. This regression was noticed by Valentin Gatien-Baron when working on a large repository, as it goes unnoticed for smaller repositories like Mercurial itself. This fix introduces the same getter/setter mechanism at `hg-core` level as for `set/get_dirs`. While this technique is, as previously discussed, quite suboptimal, it fixes an important enough problem. Refactoring `hg-core` to use the typestate pattern could be a good approach to improving code quality in a future patch. This is a graft of stable of 83b2b829c94e Differential Revision: https://phab.mercurial-scm.org/D8110
Tue, 11 Feb 2020 19:53:56 +0900 chgserver: spawn new process if schemes change stable
Yuya Nishihara <yuya@tcha.org> [Tue, 11 Feb 2020 19:53:56 +0900] rev 44325
chgserver: spawn new process if schemes change The schemes extension updates hg.schemes table. It's technically possible for hg.repository() to look for e.g. ui.schemes instead of depending on module-local table, but I don't think the change would make much sense since [schemes] is usually specified in ~/.hgrc and thus it can be considered static data.
Mon, 10 Feb 2020 15:52:52 -0800 tests: accept new bzr message about switching branches stable
Martin von Zweigbergk <martinvonz@google.com> [Mon, 10 Feb 2020 15:52:52 -0800] rev 44324
tests: accept new bzr message about switching branches The new version apparently prints "Switched to branch at " instead of "Switched to branch: ". Differential Revision: https://phab.mercurial-scm.org/D8106
Wed, 15 Jan 2020 15:49:45 +0100 nodemap: keep track of the docket for loaded data
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 15 Jan 2020 15:49:45 +0100] rev 44323
nodemap: keep track of the docket for loaded data To perform incremental update of the on disk data, we need to keep tracks of some aspect of that data. Differential Revision: https://phab.mercurial-scm.org/D7885
Wed, 15 Jan 2020 15:49:35 +0100 nodemap: introduce an explicit class/object for the docket
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 15 Jan 2020 15:49:35 +0100] rev 44322
nodemap: introduce an explicit class/object for the docket We are about to add more information to this docket, having a clear location to stock them in memory will help. Differential Revision: https://phab.mercurial-scm.org/D7884
Wed, 15 Jan 2020 15:49:26 +0100 nodemap: keep track of the ondisk id of nodemap blocks
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 15 Jan 2020 15:49:26 +0100] rev 44321
nodemap: keep track of the ondisk id of nodemap blocks If we are to incrementally update the files, we need to keep some details about the data we read. Differential Revision: https://phab.mercurial-scm.org/D7883
Wed, 15 Jan 2020 15:49:16 +0100 nodemap: provide the on disk data to indexes who support it
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 15 Jan 2020 15:49:16 +0100] rev 44320
nodemap: provide the on disk data to indexes who support it Time to start defining the API and prepare the rust index support. We provide a method to do so. We use a distinct method instead of passing them in the constructor because we will need this method anyway later (to refresh the mmap once we update the data on disk). Differential Revision: https://phab.mercurial-scm.org/D7847
Wed, 15 Jan 2020 15:49:06 +0100 nodemap: all check that revision and nodes match in the nodemap
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 15 Jan 2020 15:49:06 +0100] rev 44319
nodemap: all check that revision and nodes match in the nodemap More check is always useful. Differential Revision: https://phab.mercurial-scm.org/D7846
Wed, 15 Jan 2020 15:48:57 +0100 nodemap: add basic checking of the on disk nodemap content
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 15 Jan 2020 15:48:57 +0100] rev 44318
nodemap: add basic checking of the on disk nodemap content The simplest check it so verify we have all the revision we needs, and nothing more. Differential Revision: https://phab.mercurial-scm.org/D7845
Wed, 15 Jan 2020 15:48:47 +0100 nodemap: code to parse the persistent binary nodemap data
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 15 Jan 2020 15:48:47 +0100] rev 44317
nodemap: code to parse the persistent binary nodemap data We now have code to read back what we persisted. This will be put to use in later changesets. Differential Revision: https://phab.mercurial-scm.org/D7844
Wed, 15 Jan 2020 15:48:38 +0100 nodemap: move the iteratio inside the Block object
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 15 Jan 2020 15:48:38 +0100] rev 44316
nodemap: move the iteratio inside the Block object Having the iteration inside the serialization function does not help readability. Now that we have a `Block` object, let us move that code there. Differential Revision: https://phab.mercurial-scm.org/D7843
Wed, 15 Jan 2020 15:48:28 +0100 nodemap: use an explicit "Block" object in the reference implementation
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 15 Jan 2020 15:48:28 +0100] rev 44315
nodemap: use an explicit "Block" object in the reference implementation This will help us to introduce some test around the data currently written on disk. Differential Revision: https://phab.mercurial-scm.org/D7842
Wed, 15 Jan 2020 15:48:19 +0100 nodemap: add a optional `nodemap_add_full` method on indexes
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 15 Jan 2020 15:48:19 +0100] rev 44314
nodemap: add a optional `nodemap_add_full` method on indexes This method can be used to obtains persistent data for a full nodemap. The end goal is for some index implementation to managed the nodemap serialization them selves (eg: the rust implementation) Differential Revision: https://phab.mercurial-scm.org/D7841
Wed, 15 Jan 2020 15:48:09 +0100 nodemap: add a (python) index class for persistent nodemap testing
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 15 Jan 2020 15:48:09 +0100] rev 44313
nodemap: add a (python) index class for persistent nodemap testing Using the persistent nodemap require a compeling performance boost and an existing implementation. The benefit of the persistent nodemap for pure python code is unclear and we don't have a C implementation for it. Yet we would like to actually start testing it in more details and define an API for using that persistent nodemap. We introduce a new `devel` config option to use an index class dedicated to Nodemap Testing. This feature is "pure" only because having using a pure-python index with the `cext` policy proved more difficult than I would like. There is nothing going on in that class for now, but the coming changeset will change that. Differential Revision: https://phab.mercurial-scm.org/D7840
Wed, 15 Jan 2020 15:47:59 +0100 nodemap: delete older raw data file when creating a new ones
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 15 Jan 2020 15:47:59 +0100] rev 44312
nodemap: delete older raw data file when creating a new ones When we write new full files, it replace an older one with a different name. We add the associated cleanup for the older file to be removed after the transaction. We delete all file matching the expected pattern to give use extra chance to delete orphan files we might have failed to delete earlier. Note: eventually we won't rewrite all data for each transaction. This is coming in later changesets. Differential Revision: https://phab.mercurial-scm.org/D7839
Wed, 15 Jan 2020 15:47:50 +0100 nodemap: use an intermediate "docket" file to carry small metadata
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 15 Jan 2020 15:47:50 +0100] rev 44311
nodemap: use an intermediate "docket" file to carry small metadata This intermediate file will make mmapping, transaction and content validation easier. (Most of this usefulness will arrive gradually in later changeset). In particular it will become very useful to append new data are the end of raw file instead of rewriting on the file on each transaction. See in code comments for details. Differential Revision: https://phab.mercurial-scm.org/D7838
Wed, 15 Jan 2020 15:47:40 +0100 nodemap: only use persistent nodemap for non-inlined revlog
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 15 Jan 2020 15:47:40 +0100] rev 44310
nodemap: only use persistent nodemap for non-inlined revlog Revlog are inlined while they are small (to avoid having too many file to deal with). The persistent nodemap will only provides a significant boost for large enough revlog index. So it does not make sens to add an extra file to store nodemap for small revlog. We could consider inclining the nodemap data inside the revlog itself, but the benefit is unclear so let it be an adventure for another time. Differential Revision: https://phab.mercurial-scm.org/D7837
Wed, 15 Jan 2020 15:47:31 +0100 nodemap: add a function to read the data from disk
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 15 Jan 2020 15:47:31 +0100] rev 44309
nodemap: add a function to read the data from disk This changeset is small and mostly an excuse to introduce an API function reading the data from disk. Differential Revision: https://phab.mercurial-scm.org/D7836
Wed, 15 Jan 2020 15:47:21 +0100 nodemap: write nodemap data on disk
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 15 Jan 2020 15:47:21 +0100] rev 44308
nodemap: write nodemap data on disk Let us start writing data on disk (so that we can read it from there later). This series of changeset is going to focus first on having data on disk and updating it. Right now the data is written right next to the revlog data, in the store. We might move it to cache (with proper cache validation mechanism) later, but for now revlog have a storevfs instance and it is simpler to us it. The right location for this data is not the focus of this series. Differential Revision: https://phab.mercurial-scm.org/D7835
Wed, 15 Jan 2020 15:47:12 +0100 nodemap: have some python code writing a nodemap in persistent binary form
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 15 Jan 2020 15:47:12 +0100] rev 44307
nodemap: have some python code writing a nodemap in persistent binary form This python code aims to be as "simple" as possible. It is a reference implementation of the data we are going to write on disk (and possibly, later a way for pure python install to make sure the on disk data are up to date). It is not optimized for performance and rebuild the full data structure from the index every time. This is a stepping stone toward a persistent nodemap on disk. Differential Revision: https://phab.mercurial-scm.org/D7834
Mon, 10 Feb 2020 17:31:05 -0500 cleanup: re-run black on the codebase
Augie Fackler <augie@google.com> [Mon, 10 Feb 2020 17:31:05 -0500] rev 44306
cleanup: re-run black on the codebase Looks like a few patches have landed without having been blackened. I strongly suspect I should write a patch for baymax that blackens things on the way in... # skip-blame automatic formatting Differential Revision: https://phab.mercurial-scm.org/D8104
Thu, 16 Jan 2020 13:34:04 +0100 rust-re2: add wrapper for calling Re2 from Rust
Raphaël Gomès <rgomes@octobus.net> [Thu, 16 Jan 2020 13:34:04 +0100] rev 44305
rust-re2: add wrapper for calling Re2 from Rust This assumes that Re2 is installed following Google's guide. I am not sure how we want to integrate it in the project, but I think a follow-up patch would be more appropriate for such work. As it stands, *not* having Re2 installed results in a compilation error, which is a problem as it breaks install compatibility. Hence, this is gated behind a non-default `with-re2` compilation feature. Differential Revision: https://phab.mercurial-scm.org/D7910
Thu, 16 Jan 2020 11:27:12 +0100 rust-filepatterns: add support for `include` and `subinclude` patterns
Raphaël Gomès <rgomes@octobus.net> [Thu, 16 Jan 2020 11:27:12 +0100] rev 44304
rust-filepatterns: add support for `include` and `subinclude` patterns This prepares a future patch for `IncludeMatcher` on the road to bare `hg status` support. Differential Revision: https://phab.mercurial-scm.org/D7909
Thu, 16 Jan 2020 10:28:40 +0100 rust-filepatterns: improve API and robustness for pattern files parsing
Raphaël Gomès <rgomes@octobus.net> [Thu, 16 Jan 2020 10:28:40 +0100] rev 44303
rust-filepatterns: improve API and robustness for pattern files parsing Within the next few patches we will be using this new API. Differential Revision: https://phab.mercurial-scm.org/D7908
Mon, 10 Feb 2020 15:50:26 -0800 tests: add workaround for bzr bug stable
Martin von Zweigbergk <martinvonz@google.com> [Mon, 10 Feb 2020 15:50:26 -0800] rev 44302
tests: add workaround for bzr bug This started failing for me today. I guess my bzr was upgraded. Differential Revision: https://phab.mercurial-scm.org/D8105
Tue, 14 Jan 2020 17:10:20 +0100 rust-utils: add util for canonical path
Raphaël Gomès <rgomes@octobus.net> [Tue, 14 Jan 2020 17:10:20 +0100] rev 44301
rust-utils: add util for canonical path Differential Revision: https://phab.mercurial-scm.org/D7871
Sat, 01 Feb 2020 09:14:36 +0100 test: simplify test-amend.t to avoid race condition stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 01 Feb 2020 09:14:36 +0100] rev 44300
test: simplify test-amend.t to avoid race condition Insted on relying on sleep, we could simply have the editor do the file change. This remove the reliance on "sleep" and avoid test failing on heavy load machine. To test this, I reverted the code change in 5558e3437872 and the test started failing again. This is a graft on stable of 141ceec06b55 which should have targeted for stable. Differential Revision: https://phab.mercurial-scm.org/D8103
Sun, 09 Feb 2020 01:34:37 +0100 remotefilelog-test: glob some flaky output line (issue6083) stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Sun, 09 Feb 2020 01:34:37 +0100] rev 44299
remotefilelog-test: glob some flaky output line (issue6083) The two following lines are flaky underload, yet the final result is correct. The command involves background pre-check of output, these are not stable probably because they run in parallel in multiple process. I spent a couple of hours trying to understand the pattern and gave up. The documented intend of these tests is safely guaranteed by checking the cache content after the command. If it become useful to start testing precise internal details of the, they will have to be tested in a more appropriate framework than `.t` tests. Differential Revision: https://phab.mercurial-scm.org/D8102
Tue, 21 Jan 2020 10:24:32 -0500 httpconnection: allow `httpsendfile` subclasses to suppress the progressbar
Matt Harbison <matt_harbison@yahoo.com> [Tue, 21 Jan 2020 10:24:32 -0500] rev 44298
httpconnection: allow `httpsendfile` subclasses to suppress the progressbar This will be neccessary for LFS, which manages the progressbar outside of the file. Differential Revision: https://phab.mercurial-scm.org/D7960
Mon, 10 Feb 2020 21:54:12 +0100 rust-dirstatemap: add `NonNormalEntries` class
Raphaël Gomès <rgomes@octobus.net> [Mon, 10 Feb 2020 21:54:12 +0100] rev 44297
rust-dirstatemap: add `NonNormalEntries` class This fix introduces the same encapsulation as the `copymap`. There is no easy way of doing this any better for now. `hg up -r null && time HGRCPATH= HGMODULEPOLICY=rust+c hg up tip` on Mozilla Central, (not super recent, but it doesn't matter): Before: 7:44,08 total After: 1:03,23 total Pretty brutal regression! Differential Revision: https://phab.mercurial-scm.org/D8049
Sun, 09 Feb 2020 16:18:26 -0500 help: when possible, indicate flags implied by tweakdefaults
Valentin Gatien-Baron <valentin.gatienbaron@gmail.com> [Sun, 09 Feb 2020 16:18:26 -0500] rev 44296
help: when possible, indicate flags implied by tweakdefaults Differential Revision: https://phab.mercurial-scm.org/D8101
Sun, 09 Feb 2020 15:50:36 -0500 help: add a mechanism to change flags' help depending on config
Valentin Gatien-Baron <valentin.gatienbaron@gmail.com> [Sun, 09 Feb 2020 15:50:36 -0500] rev 44295
help: add a mechanism to change flags' help depending on config It seems reasonable to have a similar mechanism for the rest of the help, but no such thing is implemented. The goal is to make the help of commands clearer in the presence of significant default changes, like tweakdefaults or with company-wide hgrcs. In these cases, a user looking at the help of a command doesn't exactly know what his hgrc is doing. Apply to this to the --git option of commands that display diffs, as this option in particular causes confusion for some reason. Differential Revision: https://phab.mercurial-scm.org/D8100
Sat, 08 Feb 2020 23:39:55 -0500 lfs: use str for the open() mode when opening a blob for py3
Matt Harbison <matt_harbison@yahoo.com> [Sat, 08 Feb 2020 23:39:55 -0500] rev 44294
lfs: use str for the open() mode when opening a blob for py3 The other fix for this was to leave the mode as bytes, and import `pycompat.open()` like a bunch of other modules do. But I think it's confusing to still use bytes at the python boundary, and obviously error prone. Grepping for ` open\(.+, ['"][a-z]+['"]\)` and ` open\(.+, b['"][a-z]+['"]\)` outside of `tests`, there are 51 and 87 uses respectively, so it's not like this is a rare direct usage. Differential Revision: https://phab.mercurial-scm.org/D8099
Thu, 30 Jan 2020 14:57:02 +0100 rust-dirstatemap: cache non normal and other parent set
Raphaël Gomès <rgomes@octobus.net> [Thu, 30 Jan 2020 14:57:02 +0100] rev 44293
rust-dirstatemap: cache non normal and other parent set Performance of `hg update` was significantly worse since the introduction of the Rust `dirstatemap`. This regression was noticed by Valentin Gatien-Baron when working on a large repository, as it goes unnoticed for smaller repositories like Mercurial itself. This fix introduces the same getter/setter mechanism at `hg-core` level as for `set/get_dirs`. While this technique is, as previously discussed, quite suboptimal, it fixes an important enough problem. Refactoring `hg-core` to use the typestate pattern could be a good approach to improving code quality in a future patch. Differential Revision: https://phab.mercurial-scm.org/D8048
(0) -30000 -10000 -3000 -1000 -300 -100 -60 +60 +100 +300 +1000 +3000 tip