Wed, 12 Jun 2019 14:18:12 +0100 rust-discovery: accept the new 'respectsize' init arg
Georges Racinet <georges.racinet@octobus.net> [Wed, 12 Jun 2019 14:18:12 +0100] rev 42735
rust-discovery: accept the new 'respectsize' init arg At this stage, we don't do anything about it: it will be meaningful in sampling methods that aren't implemented yet. Differential Revision: https://phab.mercurial-scm.org/D6516
Wed, 14 Aug 2019 09:22:54 +0900 merge with stable
Yuya Nishihara <yuya@tcha.org> [Wed, 14 Aug 2019 09:22:54 +0900] rev 42734
merge with stable
Tue, 13 Aug 2019 22:48:05 +0530 unshelve: forget unknown files after a partial unshelve
Navaneeth Suresh <navaneeths1998@gmail.com> [Tue, 13 Aug 2019 22:48:05 +0530] rev 42733
unshelve: forget unknown files after a partial unshelve This is a follow-up patch to 6957f7b93e03. This allows hg to forget unknown files after a partial unshelve. Differential Revision: https://phab.mercurial-scm.org/D6724
Thu, 08 Aug 2019 01:59:43 +0200 flagutil: move addflagprocessor to the new module (API)
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 08 Aug 2019 01:59:43 +0200] rev 42732
flagutil: move addflagprocessor to the new module (API)
Thu, 08 Aug 2019 01:25:37 +0200 flagutil: move insertflagprocessor to the new module (API)
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 08 Aug 2019 01:25:37 +0200] rev 42731
flagutil: move insertflagprocessor to the new module (API)
Thu, 08 Aug 2019 01:28:34 +0200 flagutil: move REVIDX_KNOWN_FLAGS source of truth in flagutil (API)
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 08 Aug 2019 01:28:34 +0200] rev 42730
flagutil: move REVIDX_KNOWN_FLAGS source of truth in flagutil (API) Since REVIDX_KNOWN_FLAGS is "not really a constant" (extension can update it) and python integer,... it needs to be the responsability of a single module and always accessed through the module. We update all the user and move the source of truth in flagutil.
Thu, 08 Aug 2019 01:04:48 +0200 flagutil: move the `flagprocessors` mapping in the new module
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 08 Aug 2019 01:04:48 +0200] rev 42729
flagutil: move the `flagprocessors` mapping in the new module This module is meant to host most of the flag processing logic. We start with the mapping between flag and processors.
Thu, 08 Aug 2019 01:03:01 +0200 flagutil: create a `mercurial.revlogutils.flagutil` module
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 08 Aug 2019 01:03:01 +0200] rev 42728
flagutil: create a `mercurial.revlogutils.flagutil` module The flagprocessings logic is duplicated in 2 extra places, and usually in a less robust flavor. This is a maintenance nightmare that I would like to see cleaned up. To do so I am creating a `flagutil` module to move flag processings related code and make it easily reusable by other code.
Wed, 07 Aug 2019 22:02:49 +0200 rawdata: register the method for `ifiledata`
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 07 Aug 2019 22:02:49 +0200] rev 42727
rawdata: register the method for `ifiledata` The interface have a `revision(..., raw=False)` method so it should get a `rawdata` one. I am not sure why nothing complained about the lack of it earlier.
Wed, 07 Aug 2019 21:17:48 +0200 rawdata: implement the method for `unionrepo` too
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 07 Aug 2019 21:17:48 +0200] rev 42726
rawdata: implement the method for `unionrepo` too This is required for all implementations.
Wed, 07 Aug 2019 20:51:52 +0200 rawdata: implement the method for `remotefilelog` too
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 07 Aug 2019 20:51:52 +0200] rev 42725
rawdata: implement the method for `remotefilelog` too This is needed for all storage implementations.
Wed, 07 Aug 2019 20:48:05 +0200 rawdata: implement `rawdata` for `simplestore` too
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 07 Aug 2019 20:48:05 +0200] rev 42724
rawdata: implement `rawdata` for `simplestore` too This is needed for all implementation.
Wed, 07 Aug 2019 22:08:04 +0200 rawdata: forward `rawdata` call on `manifestlog`
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 07 Aug 2019 22:08:04 +0200] rev 42723
rawdata: forward `rawdata` call on `manifestlog` This needs to be sent to the underlying `revlog` too.
Wed, 07 Aug 2019 22:01:52 +0200 rawdata: implement `rawdata` for `sqlitestore` too
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 07 Aug 2019 22:01:52 +0200] rev 42722
rawdata: implement `rawdata` for `sqlitestore` too This is a different store, it needs it declared.
Wed, 07 Aug 2019 22:00:57 +0200 rawdata: add the method to bundlerevlog
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 07 Aug 2019 22:00:57 +0200] rev 42721
rawdata: add the method to bundlerevlog The bundlerepo logic has its own `revision` method on its own `revlog` object. We need to "implement" `rawdata` there too.
Wed, 07 Aug 2019 21:59:20 +0200 rawdata: forward the method call on `filelog` object
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 07 Aug 2019 21:59:20 +0200] rev 42720
rawdata: forward the method call on `filelog` object We have a new method, we need to expose it.
Wed, 07 Aug 2019 21:54:29 +0200 rawdata: introduce a `rawdata` method on revlog
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 07 Aug 2019 21:54:29 +0200] rev 42719
rawdata: introduce a `rawdata` method on revlog This method aims at replacing `revision(..., raw=True)` call. The purpose of data returned without and without raw are different enough that having two different method would make sense. This split is motivated by other work aiming at storing data on the side of the main revision of a revlog. Having a cleaner API makes it simpler to add this work. The series following this first changesets is organised as follow: 1) add `rawdata` method everywhere it is useful 2) update all caller 3) implement all `rawdata` method without using `revision` 4) deprecate the `rawdata` parameter of `revision`
Wed, 07 Aug 2019 17:14:48 +0200 revlog: split a `_revisiondata` method to file `revision` job
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 07 Aug 2019 17:14:48 +0200] rev 42718
revlog: split a `_revisiondata` method to file `revision` job We are about to introduce more public method to access revision data (eg: `rawdata`). revset subclass tend to recursively call `revision` which will create all kind of issue with the coming series. To avoid them we introduce an explicit difference between the internal call and the public all. This will be useful for later work anyway (so the subclass issue is just moving it earlier in the series). I am not sure if the subclass are actually doing something sensible. However, I am certain I don't want to be rabbit holed into figuring it out right now.
Wed, 24 Jul 2019 18:32:36 +0530 continue: added support for transplant
Taapas Agrawal <taapas2897@gmail.com> [Wed, 24 Jul 2019 18:32:36 +0530] rev 42717
continue: added support for transplant This creates a seperate function `continuetransplant()` containing logic for resuming transplant from interrupted state. `continuetransplant()` is then registered as `continuefunc` for state detection API. Results are shown in tests. Differential Revision: https://phab.mercurial-scm.org/D6689
Fri, 09 Aug 2019 05:09:54 -0400 merge with stable
Augie Fackler <augie@google.com> [Fri, 09 Aug 2019 05:09:54 -0400] rev 42716
merge with stable
Mon, 12 Aug 2019 14:00:19 -0400 fncache: make debugrebuildfncache not fail on broken fncache stable
Valentin Gatien-Baron <vgatien-baron@janestreet.com> [Mon, 12 Aug 2019 14:00:19 -0400] rev 42715
fncache: make debugrebuildfncache not fail on broken fncache The code reading the fncache changed in 5.0, to complain if the file is not \n terminated. This makes apparent the fact that the fncache gets corrupted. Make it possible to recover, instead of having `hg debugrebuildfncache` failing by saying `(run hg debugrebuildfncache)`. The corruption itself is most likely due to hg not using fsync in general, and so various bad things can happen. Here, the reported problems happened when running out of disk space. So I suspect that because the fncache is much bigger than the average commit/pull, when running out of disk space, the bulk of the pull may succeed, but the new fncache may get half-written and still renamed into place. Differential Revision: https://phab.mercurial-scm.org/D6722
Mon, 12 Aug 2019 13:22:27 -0400 fncache: show that debugrebuildfncache is partly broken stable
Valentin Gatien-Baron <vgatien-baron@janestreet.com> [Mon, 12 Aug 2019 13:22:27 -0400] rev 42714
fncache: show that debugrebuildfncache is partly broken Differential Revision: https://phab.mercurial-scm.org/D6721
Fri, 09 Aug 2019 13:11:27 +0200 test: further fixes to matching for run-tests.py bug stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 09 Aug 2019 13:11:27 +0200] rev 42713
test: further fixes to matching for run-tests.py bug The fix in bac24a8a095a did not fix the full issue, because the extra number also eat some of the separator space. Since we are already matching arbitrary number of space, we easily fix the matching.
Mon, 05 Aug 2019 13:31:12 -0700 branchmap: explicitly warm+write all subsets of the branchmap caches
Kyle Lippincott <spectral@google.com> [Mon, 05 Aug 2019 13:31:12 -0700] rev 42712
branchmap: explicitly warm+write all subsets of the branchmap caches 'full' claims it will warm all of the caches that are known about, but this was not the case - it did not actually warm the branchmap caches for subsets that we haven't requested, or for subsets that are still considered "valid". By explicitly writing them to disk, we can force the subsets for ex: "served" to be written ("immutable" and "base"), making it cheaper to calculate "served" the next time it needs to be updated. Differential Revision: https://phab.mercurial-scm.org/D6710
Wed, 12 Jun 2019 13:42:52 +0100 changectx: extract explicit computechangesetfilesremoved method from context
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 12 Jun 2019 13:42:52 +0100] rev 42711
changectx: extract explicit computechangesetfilesremoved method from context Right now, the logic around changeset centric removed files data are buried into the "changectx" code. We extract this code in a dedicated method (in the scmutil module) for clarity. This clarity will help to explicitly compute and caches these data in the future.
Wed, 12 Jun 2019 13:42:22 +0100 changectx: extract explicit computechangesetfilesadded method from context
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 12 Jun 2019 13:42:22 +0100] rev 42710
changectx: extract explicit computechangesetfilesadded method from context Right now, the logic around changeset centric added files data are buried into the "changectx" code. We extract this code in a dedicated method (in the scmutil module) for clarity. This clarity will help to explicitly compute and caches these data in the future.
Thu, 08 Aug 2019 11:06:13 +0200 demandimport: explicitly declare `_session` at the module level stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 08 Aug 2019 11:06:13 +0200] rev 42709
demandimport: explicitly declare `_session` at the module level The `_session` module level variable is set within a function using the `global` keyword. This confuses my `test-check-pyflakes.t`. Explicitly declaring the variable at the top level solves the issue (and seems absolutely reasonable).
Thu, 08 Aug 2019 10:55:06 +0200 tests: give more room for slowness in test-run-tests.t stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 08 Aug 2019 10:55:06 +0200] rev 42708
tests: give more room for slowness in test-run-tests.t The test expected any run-test.py run to end in less than 10 seconds. On slower loaded CI machine, this gets slower than that. We give a bit more room to the regexp.
Tue, 06 Aug 2019 03:17:40 +0200 copies: extract an explicit `computechangesetcopie` method from context
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 06 Aug 2019 03:17:40 +0200] rev 42707
copies: extract an explicit `computechangesetcopie` method from context Right now, the logic around changeset centric copies data are buried into the "changectx" code. We extract this code in a dedicated method (in the copies module) for clarity. This clarity will help to explicitly compute and caches these data in the future.
Wed, 07 Aug 2019 19:18:20 +0530 config: fix fm.data() handling of defaultvalue
Navaneeth Suresh <navaneeths1998@gmail.com> [Wed, 07 Aug 2019 19:18:20 +0530] rev 42706
config: fix fm.data() handling of defaultvalue This is a follow-up patch to rHG51a2e3102db2. This moves `fm.data()` out of the if block in `commands.config()`. Differential Revision: https://phab.mercurial-scm.org/D6720
(0) -30000 -10000 -3000 -1000 -300 -100 -50 -30 +30 +50 +100 +300 +1000 +3000 tip