Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 17 Apr 2019 01:12:21 +0200] rev 42197
verify: introduce a notion of "level"
Some checks are slower than others, to help the user to run the checks he needs,
we are about to introduce new flag to select faster vs deeper runs. This put
the scaffolding in place to do this.
Martin von Zweigbergk <martinvonz@google.com> [Sat, 13 Apr 2019 23:18:56 -0700] rev 42196
tests: split out separate test for issue5020
The test was added to the existing setup in 41f6af50c0d8 (merge: fix
crash on criss cross merge with dir move and delete (issue5020),
2017-01-31). I'm about to make a change that affects that test and
it's much easier to follow if the test case for issue5020 is a
separate test case. The separate test case is based on what mpm
provided in comment 12 on the issue.
`hg diff -r 41f6af50c0d8^ tests/test-merge-criss-cross.t` after this
patch is pretty small (besides the added test). It's probably easier
for reviewers to look at that than to try to understand the diff
itself (I don't understand it).
Differential Revision: https://phab.mercurial-scm.org/D6243
Martin von Zweigbergk <martinvonz@google.com> [Mon, 15 Apr 2019 18:04:54 -0700] rev 42195
tests: avoid a rename/delete conflict when updating in test-narrow-update.t
After the upcoming rewrite of mergecopies(), this test would otherwise
(accurately) start warning about "inside/f1 was deleted and renamed".
Differential Revision: https://phab.mercurial-scm.org/D6254
Martin von Zweigbergk <martinvonz@google.com> [Mon, 15 Apr 2019 15:28:41 -0700] rev 42194
tests: delete unused function in test-rename-merge2.t
Differential Revision: https://phab.mercurial-scm.org/D6253
Martin von Zweigbergk <martinvonz@google.com> [Sun, 14 Apr 2019 13:46:40 -0700] rev 42193
tests: make merge conflicts explicit in `hg annotate` tests
We were using `true` as merge tool. I think it makes the test easier
to understand if we make the conflicts explcit. It also papered over a
conflict that shouldn't have been a conflict (just a bug in copy
tracing). I've marked that "BROKEN".
Differential Revision: https://phab.mercurial-scm.org/D6252
Martin von Zweigbergk <martinvonz@google.com> [Thu, 18 Apr 2019 03:05:42 +0530] rev 42192
narrow: make warning about possibly dirty files respect ui.relative-paths
Differential Revision: https://phab.mercurial-scm.org/D6264
Augie Fackler <raf@durin42.com> [Tue, 09 Jul 2019 10:07:35 -0400] rev 42191
Added signature for changeset 97ada9b8d51b
Augie Fackler <raf@durin42.com> [Tue, 09 Jul 2019 10:07:33 -0400] rev 42190
Added tag 5.0.2 for changeset 97ada9b8d51b
Augie Fackler <augie@google.com> [Mon, 08 Jul 2019 13:12:20 -0400] rev 42189
posix: always seek to EOF when opening a file in append mode
Python 3 already does this, so skip it there.
Consider the program:
#include <stdio.h>
int main() {
FILE *f = fopen("narf", "w");
fprintf(f, "narf\n");
fclose(f);
f = fopen("narf", "a");
printf("%ld\n", ftell(f));
fprintf(f, "troz\n");
printf("%ld\n", ftell(f));
return 0;
}
on macOS, FreeBSD, and Linux with glibc, this program prints
5
10
but on musl libc (Alpine Linux and probably others) this prints
0
10
By my reading of
https://pubs.opengroup.org/onlinepubs/009695399/functions/fopen.html
this is technically correct, specifically:
> Opening a file with append mode (a as the first character in the
> mode argument) shall cause all subsequent writes to the file to be
> forced to the then current end-of-file, regardless of intervening
> calls to fseek().
in other words, the file position doesn't really matter in append-mode
files, and we can't depend on it being at all meaningful unless we
perform a seek() before tell() after open(..., 'a'). Experimentally
after a .write() we can do a .tell() and it'll always be reasonable,
but I'm unclear from reading the specification if that's a smart thing
to rely on. This matches what we do on Windows and what Python 3 does
for free, so let's just be consistent. Thanks to Yuya for the idea.
Anton Shestakov <av6@dwimlabs.net> [Wed, 03 Jul 2019 10:06:39 +0800] rev 42188
move: --force flag forcibly moves, not copies
Anton Shestakov <av6@dwimlabs.net> [Wed, 03 Jul 2019 10:01:51 +0800] rev 42187
copy: correct synopsis by making SOURCE a required argument
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 02 Jul 2019 10:53:29 +0200] rev 42186
debugrevlog: fix average size computation for empty data (issue6167)
If the file has no full snapshot (eg: was always empty), `hg debugrevlog` would
fails when trying to compute their average size.
Matt Harbison <matt_harbison@yahoo.com> [Sat, 29 Jun 2019 23:23:07 -0400] rev 42185
bookmarks: backout the attempt to fix the delete race
This backs out 044045dce23a because it broke a bunch of tests on Windows.
Yuya's theory is that we still rely on in-memory changelog data to be flushed
out of the transaction.
Matt Harbison <matt_harbison@yahoo.com> [Sat, 22 Jun 2019 23:04:52 -0400] rev 42184
help: add a missing blank line to unhide `revlog-compression`
The help was output, but it was elided with "Enabled by default" from the
previous item.
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 21 Jun 2019 03:50:40 +0200] rev 42183
bookmarks: actual fix for race condition deleting bookmark
This is a simple but efficient fix to prevent the issue tested in
`test-bookmarks-corner-case.t`. It might be worth pursuing a more generic
approach where filecache learn to depend on each other, but that would not be
suitable for stable.
The issue is complicated enough that I documented the race and its current
solution as inline comment. See this comment for details on the fix.
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 21 Jun 2019 03:50:06 +0200] rev 42182
localrepo: introduce a `_refreshchangelog` method
See next changeset for usage and documentation for details.
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 19 Jun 2019 17:26:19 +0200] rev 42181
bookmarks: actually trigger the race deleting bookmark in the test
The previous committed version of the test did not triggered the race, but this
was hidden by a strange behavior from the test runner.
So we are moving the test to a slightly more complex that actually trigger the
issue.
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 19 Jun 2019 17:26:16 +0200] rev 42180
test: add some assert in the bookrace extension
This cannot hurt to have a bit more security in the test extension.
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 19 Jun 2019 05:46:07 +0200] rev 42179
test: factor out the "wait" logic in bookrace
The test is currently not testing the race it is supposed to test. The
synchronisation is still valid, but needs to run at a different point.
We start with extracting the synchronisation logic for clarity.
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 19 Jun 2019 05:45:44 +0200] rev 42178
test: remove dead code in the bookrace extension
This code is the remain of a previous version of the code. It is never ran, so
we can remove it.
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 19 Jun 2019 05:37:33 +0200] rev 42177
run-tests: stop matching line for missing feature
Before this change, the following unified test input would silently pass
$ echo foo
foo (false !)
After this change, the "foo" output is properly detected as unexpected.
The output of an handful of test had to be updated from broken conditional (that
ended up working by chance).
Yuya Nishihara <yuya@tcha.org> [Sun, 16 Jun 2019 12:31:07 +0900] rev 42176
cborutil: fix streamencode() to handle subtypes
Otherwise the template filter 'cbor' could crash because of bytes subclass:
ValueError: do not know how to encode
<class 'mercurial.encoding.safelocalstr'>
Martin von Zweigbergk <martinvonz@google.com> [Fri, 31 May 2019 22:37:14 -0700] rev 42175
bookmarks: use correct store for "ambiguity check"
I still don't quite know what the check does, but I clearly got it
wrong in 526750cdd02d (bookmarks: keep bookmarks in .hg/store if new
config set, 2019-05-15). Just compare with the strings we use in
@repofilecache and @storecache. These bugs were then copied to the
stable branch in c2b83c957621 (localrepo: grab mixedrepostorecache
class from 526750cdd02d, 2019-05-20) and 2338bdea4474 (bookmark: also
make bookmark cache depends of the changelog, 2019-05-20). As a
result, test-wireproto-exchangev2.t is flaky on both branches. This
patch fixes that.
Differential Revision: https://phab.mercurial-scm.org/D6469
Augie Fackler <raf@durin42.com> [Wed, 05 Jun 2019 10:14:19 -0400] rev 42174
Added signature for changeset c3484ddbdb96
Augie Fackler <raf@durin42.com> [Wed, 05 Jun 2019 10:14:18 -0400] rev 42173
Added tag 5.0.1 for changeset c3484ddbdb96
Matt Harbison <matt_harbison@yahoo.com> [Thu, 23 May 2019 22:50:11 -0400] rev 42172
manifest: add some documentation to _lazymanifest python code
It was not particularly easy figuring out the design of this class and keeping
track of how the pieces work. So might as well write some of it down for the
next person.
Matt Harbison <matt_harbison@yahoo.com> [Thu, 23 May 2019 21:54:24 -0400] rev 42171
manifest: avoid corruption by dropping removed files with pure (issue5801)
Previously, removed files would simply be marked by overwriting the first byte
with NUL and dropping their entry in `self.position`. But no effort was made to
ignore them when compacting the dictionary into text form. This allowed them to
slip into the manifest revision, since the code seems to be trying to minimize
the string operations by copying as large a chunk as possible. As part of this,
compact() walks the existing text based on entries in the `positions` list, and
consumed everything up to the next position entry. This typically resulted in
a ValueError complaining about unsorted manifest entries.
Sometimes it seems that files do get dropped in large repos- it seems to
correspond to there being a new entry that would take the same slot. A much
more trivial problem is that if the only changes were removals, `_compact()`
didn't even run because `__delitem__` doesn't add anything to `self.extradata`.
Now there's an explicit variable to flag this, both to allow `_compact()` to
run, and to avoid searching the manifest in cases where there are no removals.
In practice, this behavior was mostly obscured by the check in fastdelta() which
takes a different path that explicitly drops removed files if there are fewer
than 1000 changes. However, timeless has a repo where after rebasing tens of
commits, a totally different path[1] is taken that bypasses the change count
check and hits this problem.
[1] https://www.mercurial-scm.org/repo/hg/file/2338bdea4474/mercurial/manifest.py#l1511
Matt Harbison <matt_harbison@yahoo.com> [Thu, 23 May 2019 21:39:19 -0400] rev 42170
tests: demonstrate broken manifest generation with the pure module
This will be fixed next. But I don't fully understand how 'b.txt' is actually
removed properly in the second test, given what's broken. Also, I'm not sure
why 'bb.txt' is flagged as not being in the manifest, when it clearly appears
to be.
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 20 May 2019 10:08:28 +0200] rev 42169
bookmark: also make bookmark cache depends of the changelog
Since the changelog is also used during the parsing of bookmark data, it should
be listed as a file cache dependency. This fix the race condition we just
introduced a test for.
This is a simple fix that might lead bookmark data to be invalidated more often
than necessary. We could have more complicated code to deal with this race in a
more "optimal" way. I feel it would be unsuitable for stable.
In addition, the performance impact of this is probably minimal and I don't
foresee the more advanced fix to actually be necessary.
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 20 May 2019 10:08:17 +0200] rev 42168
localrepo: grab mixedrepostorecache class from 526750cdd02d
On default, Martin von Zweigbergk <martinvonz@google.com> introduced a more
advance filecache decorator. I need this decorator to fix a bug on stable. So I
am grafting the relevant part of 526750cdd02d.