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.
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`
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.
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
Augie Fackler <augie@google.com> [Fri, 09 Aug 2019 05:09:54 -0400] rev 42716
merge with 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
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
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.
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
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.
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.
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).
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.
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.
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 rHG
51a2e3102db2. This moves
`fm.data()` out of the if block in `commands.config()`.
Differential Revision: https://phab.mercurial-scm.org/D6720