Simon Sapin <simon.sapin@octobus.net> [Mon, 11 Jan 2021 13:33:00 +0100] rev 46697
copies-rust: add a macro-based unit-testing framework
`compare_values`, `merge_copies_dict`, and `CombineChangesetCopies`
are APIs whose signatures involve non-trivial types.
Calling them directly in unit tests would involve a lot of verbose
setup code that obscures the meaningful parts of a given test case.
This adds a macro-based test-harness with pseudo-syntax to tersely
create arguments and expected return values in the correct types.
For now there is only one (not particularly meaningful) test case
per tested function, just to exercize the macros.
Differential Revision: https://phab.mercurial-scm.org/D10071
Simon Sapin <simon.sapin@octobus.net> [Wed, 06 Jan 2021 23:11:59 +0100] rev 46696
copies-rust: rewrite ChangedFiles binary parsing
by using the new from-bytes-safe crate and a custom struct
that encodes the expected data structure.
Differential Revision: https://phab.mercurial-scm.org/D10068
Pulkit Goyal <7895pulkit@gmail.com> [Tue, 02 Mar 2021 00:02:25 +0530] rev 46695
tags: validate nodes in _getfnodes() and update cache in case of unknown nodes
`hgtagsfnodescache` can contain unknown nodes due to cache corruption and this
lead to a traceback on operations like `hg tags` as we don't validate nodes.
This patch validates that all filenodes returned after `hgtagsfnodescache` are
known to the repository. If there exists any unknown filenode, we force
recompute it and update the cache.
The test change demonstrates the fix.
Differential Revision: https://phab.mercurial-scm.org/D10083
Pulkit Goyal <7895pulkit@gmail.com> [Mon, 15 Feb 2021 17:08:18 +0530] rev 46694
debugtagscache: verify that filenode is correct
Previous patch from Matt demonstrates that `debugtagscache` does not warn about
filenode being unknown which can be caused by a corrupted cache.
We start by showing that it's an unknown node.
Differential Revision: https://phab.mercurial-scm.org/D10015
Matt Harbison <matt_harbison@yahoo.com> [Thu, 24 Dec 2020 12:23:46 -0500] rev 46693
tests: demonstrate a case where a corrupt tag cache causes an abort
I happened to hit this trying to cover other cases around valid vs missing
entries. I have no idea if this is something that could occur more naturally
(similar to how a missing file node in `hgtagsfnodes1` can occur after a strip).
There is a test just above this added in f5a7cf0adb12 mentioning it "overwrites
the junk", though that tests truncation instead of actual garbage.
But since this is just a cache, it probably shouldn't abort with a cryptic
message like this. The two options I see both have downsides- either rebuild
the cache (and potentially take a long time), or hint to the user to run a debug
command.
Differential Revision: https://phab.mercurial-scm.org/D9812
Pulkit Goyal <7895pulkit@gmail.com> [Tue, 16 Feb 2021 20:38:14 +0530] rev 46692
debugcommands: prevent using `is False`
I was touching this code in a future patch and marmoute warned about usage of
`is False` here.
Quoting marmoute:
```
"is False" is going to check if the object you have the very same object in
memory than the one Python allocated for False (in practice 0)
This will "mostly work" on cpython because of implementation details, but
is semantically wrong and can start breaking unexpectedly
```
Differential Revision: https://phab.mercurial-scm.org/D10014
Pulkit Goyal <7895pulkit@gmail.com> [Tue, 16 Feb 2021 18:43:42 +0530] rev 46691
hgtagsfnodes: refactor code to compute fnode into separate fn
I plan to use this code at one more place while fixing a bug caused by an
invalid fnode present in cache.
Differential Revision: https://phab.mercurial-scm.org/D10013
Pulkit Goyal <7895pulkit@gmail.com> [Wed, 10 Feb 2021 17:24:54 +0530] rev 46690
error: remove shortening of node in error message
This strips the complete 20 bytes node which was not found. Having the the full
node in error message is important as it makes debugging easier.
If a short node is to be displayed, that should be done by callers.
Differential Revision: https://phab.mercurial-scm.org/D9994
Martin von Zweigbergk <martinvonz@google.com> [Thu, 04 Mar 2021 08:20:19 -0800] rev 46689
copies: filter out copies grafted from another branch
Consider this simple history:
```
@ 3 modify y
|
o 2 copy x to y, modify x
|
| o 1 copy x to y, modify x
|/
o 0 add x
```
If we now rebase commit 3 onto 1, Mercurial will look for copies
between commit 2 and commit 1. It does that by going backwards from 2
to 0 and then forwards from 0 to 1. It will find that x was copied to
y, since that was what happened on the path between them (namely in
commit 1). That leads Mercurial to do a 3-way merge between y@3 and
y@1 with x@2 as base. We want to use y@2 as base instead. That's also
what happened until commit 1d6d1a15. This patch fixes the regression
by adding another filtering step when chaining copies via a
diffbase. The new filtering step removes copies that were the same
between the two branches (same source and destination, but not
necessarily the same contents).
Differential Revision: https://phab.mercurial-scm.org/D10120
Martin von Zweigbergk <martinvonz@google.com> [Fri, 05 Mar 2021 14:26:56 -0800] rev 46688
copies: inline _backwardrenames() in pathcopies()
I'll add another filtering step in `patchcopies()` next. I need access
to the forward copies for that.
Differential Revision: https://phab.mercurial-scm.org/D10119