Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 20 May 2019 10:08:28 +0200] rev 42324
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 42323
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.
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 20 May 2019 10:06:53 +0200] rev 42322
bookmark: add a test for a race condition on push
Bookmark pointing to unknown nodes are ignored. Later these ignored bookmarks
are dropped when writing the file back on disk. On paper, this behavior should
be fine, but with the current implementation, it can lead to unexpected
bookmark deletions.
In theory, to make sure writer as a consistent view, taking the lock also
invalidate bookmark data we already loaded into memory. However this
invalidation is incomplete. The data are stored in a `filecache` that preserve
them if the bookmark related file are untouched. In practice, the bookmark data
in memory also depends of the changelog content, because of the step checking
if the bookmarks refers to a node known to the changelog. So if the bookmark
data were loaded from an up to date bookmark file but filtered with an outdated
changelog file this go undetected.
This condition is fairly specific, but can occurs very often in practice. We
introduce a test recreating the situation. The test comes in an independant
changeset to show it actually reproduce the situation. The fix will come soon
after.
A large share of the initial investigation of this race condition was made by
Valentin Gatien-Baron <valentin.gatienbaron@gmail.com>.
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 20 May 2019 07:11:16 +0200] rev 42321
test: properly gate a zstd section
This part of the test can't run if zstd is not available. This was caught by
--pure test (who don't support zstd).
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 20 May 2019 07:11:06 +0200] rev 42320
test: update test for expected test output
In
1fac9b931d46 as new test session was introduced. It did not take in account
some part that only ran for pure.
The test is now fixed.
Yuya Nishihara <yuya@tcha.org> [Thu, 16 May 2019 08:15:20 +0900] rev 42319
log: flag topo-sorted set as such
This isn't required right now, but revs.istopo() should return True.
Martin von Zweigbergk <martinvonz@google.com> [Wed, 09 Jan 2019 15:54:45 -0800] rev 42318
copies: fix duplicatecopies() with overlay context
The reasoning for this check is in
78d760aa3607 (duplicatecopies: do
not mark items not in the dirstate as copies, 2013-03-28). The check
was then moved to workingfilectx in
754b5117622f (context: add
workingfilectx.markcopied, 2017-10-15) and no corresponding check was
added later when overlayworkingfilectx was added. Rather than adding
the check there, this patch adds a more generic check on the callers
side and removes the check in workingfilectx.markcopied().
Differential Revision: https://phab.mercurial-scm.org/D6380
Martin von Zweigbergk <martinvonz@google.com> [Wed, 15 May 2019 16:10:52 -0700] rev 42317
tests: demonstrate crash when rebasing across copy with --collapse
As reported by timeless.
Differential Revision: https://phab.mercurial-scm.org/D6379
Augie Fackler <augie@google.com> [Wed, 15 May 2019 17:18:57 -0400] rev 42316
exthelper: add some semi-useful trace logs
It'd be nice to make the trace functions a little better-named in the output,
but I'm not sure how much better we can do without overhead. This at least
lets you see if a single reposetup function is eating all the time or if it's
spread over all of them. I needed this because Google's uber-extension has a
long load time and I wasn't sure where the problem was.
Differential Revision: https://phab.mercurial-scm.org/D6381
Martin von Zweigbergk <martinvonz@google.com> [Wed, 15 May 2019 23:26:05 -0700] rev 42315
help: add missing blank line, making "revlog-compression" show up
Differential Revision: https://phab.mercurial-scm.org/D6386