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 42739
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 42738
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 42737
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 42736
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 42735
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 42734
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 42733
merge with stable
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 42732
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 42731
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 42730
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.
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 42729
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 42728
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 42727
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 42726
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 42725
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 42724
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 42723
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 42722
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.
Thu, 18 Jul 2019 17:10:38 +0800 revset: drop argument when it's None
Anton Shestakov <av6@dwimlabs.net> [Thu, 18 Jul 2019 17:10:38 +0800] rev 42721
revset: drop argument when it's None getstack's definition is `getstack(repo, rev=None)`, so providing None explicitly is unnecessary. Moreover, when x is not None, it's definitely not a revision but a part of a parsed tree of revset arguments. Differential Revision: https://phab.mercurial-scm.org/D6707
Thu, 18 Jul 2019 17:07:34 +0800 stack: remove unnecessary reverse() predicate
Anton Shestakov <av6@dwimlabs.net> [Thu, 18 Jul 2019 17:07:34 +0800] rev 42720
stack: remove unnecessary reverse() predicate Stack already sorts revisions, so no need to do it twice. This change was a part of D2400, which didn't land for other reasons. See also D2399, where this change was suggested. Differential Revision: https://phab.mercurial-scm.org/D6706
Sat, 03 Aug 2019 16:47:49 -0700 automation: increase root volume size on Linux
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 03 Aug 2019 16:47:49 -0700] rev 42719
automation: increase root volume size on Linux It is close to full in the AMI. I actually ran out of space running tests without increasing the volume size! Differential Revision: https://phab.mercurial-scm.org/D6716
Sat, 03 Aug 2019 16:03:11 -0700 automation: install Rust in Linux environment
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 03 Aug 2019 16:03:11 -0700] rev 42718
automation: install Rust in Linux environment This will install Rust 1.31.1, 1.34.2, and whatever stable is at the time the install runs. We install 1.31.1 as our minimum supported Rust version (I think that's what we're currently targeting) and 1.34 because that's what Debian 10 is shipping. Differential Revision: https://phab.mercurial-scm.org/D6715
Sat, 03 Aug 2019 14:17:41 -0700 automation: update packages in requirements files
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 03 Aug 2019 14:17:41 -0700] rev 42717
automation: update packages in requirements files We like keeping up to date. The content of the autogenerated files changed slightly because I used a newer version of `pip-compile` than what was used previously. Differential Revision: https://phab.mercurial-scm.org/D6714
Sat, 03 Aug 2019 14:04:31 -0700 automation: install latest Python versions
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 03 Aug 2019 14:04:31 -0700] rev 42716
automation: install latest Python versions This required bumping the pyenv commit so the new versions are available. Differential Revision: https://phab.mercurial-scm.org/D6713
(0) -30000 -10000 -3000 -1000 -300 -100 -50 -24 +24 +50 +100 +300 +1000 +3000 tip