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
Sat, 03 Aug 2019 12:14:34 +0530 config: remove pycompat.bytestr() for defaultvalue
Navaneeth Suresh <navaneeths1998@gmail.com> [Sat, 03 Aug 2019 12:14:34 +0530] rev 42705
config: remove pycompat.bytestr() for defaultvalue This is a follow-up patch to 51a2e3102db2. This removes `pycompat.bytestr` to preserve `None` in `commands.config()`. Differential Revision: https://phab.mercurial-scm.org/D6712
Sat, 27 Jul 2019 12:19:51 +0530 unshelve: clear shelvedstate and _finishunshelve() on partial unshelve
Navaneeth Suresh <navaneeths1998@gmail.com> [Sat, 27 Jul 2019 12:19:51 +0530] rev 42704
unshelve: clear shelvedstate and _finishunshelve() on partial unshelve On a partial unshelve, `shelvedstate` was not cleared and `_finishunshelve()` was not called. Ideally, these should be called on this case. This patch makes `shelvedstate` to delete after a successful partial unshelve and calls `_finishunshelve()` in the same case. Differential Revision: https://phab.mercurial-scm.org/D6708
Thu, 25 Jul 2019 22:01:15 +0530 unshelve: delete shelvedstate after a successful unshelve --continue
Navaneeth Suresh <navaneeths1998@gmail.com> [Thu, 25 Jul 2019 22:01:15 +0530] rev 42703
unshelve: delete shelvedstate after a successful unshelve --continue `unshelve --continue` was preventing the deletion of `shelvedstate` on a partial `unshelve`. Ideally, `shelvedstate` should be deleted after a successful `unshelve`. Now, the behavior of `unshelve --continue` will be as follows in interactive mode: 1] The user tried to `unshelve` changes interactively but, ran into conflicts. 2] They resolved the conflicts and triggered `unshelve --continue` but, unshelved changes partially. 3] Now, on trying to do `unshelve --continue` again will abort as the last `unshelve` was successful and we are deleting the `shelvedstate`. 4] If they want to unshelve the remaining shelved change, they need to trigger `unshelve` without `--continue`. Differential Revision: https://phab.mercurial-scm.org/D6694
Wed, 24 Jul 2019 18:15:27 +0530 unshelve: handle stripping changesets on interactive mode
Navaneeth Suresh <navaneeths1998@gmail.com> [Wed, 24 Jul 2019 18:15:27 +0530] rev 42702
unshelve: handle stripping changesets on interactive mode On interactive mode, changesets on `nodestoremove` should be stripped regardless of the shelve is partial or not. This patch modifies `unshelvecontinue()` to do that. Differential Revision: https://phab.mercurial-scm.org/D6686
Tue, 06 Aug 2019 14:54:25 +0200 byteify-strings: add --version argument
Raphaël Gomès <rgomes@octobus.net> [Tue, 06 Aug 2019 14:54:25 +0200] rev 42701
byteify-strings: add --version argument This is indispensable for automated tools to detect changes in behavior.
Tue, 06 Aug 2019 14:49:30 +0200 byteify-strings: add space in special comments to silence flake8 error
Raphaël Gomès <rgomes@octobus.net> [Tue, 06 Aug 2019 14:49:30 +0200] rev 42700
byteify-strings: add space in special comments to silence flake8 error This is done soon enough that nobody has had the time to use this feature yet.
(0) -30000 -10000 -3000 -1000 -300 -100 -50 -28 +28 +50 +100 +300 +1000 +3000 tip