( )⚙ D12097 branchmap: skip obsolete revisions while computing heads

This is an archive of the discontinued Mercurial Phabricator instance.

branchmap: skip obsolete revisions while computing heads
ClosedPublic

Authored by av6 on Jan 28 2022, 12:38 PM.

Details

Summary

It's time to make this part of core Mercurial obsolescence-aware.

Not considering obsolete revisions when computing heads is clearly what
Mercurial should do. But there are a couple of small issues:

  • Let's say tip of the repo is obsolete. There are two ways of finding tiprev for branchcache (both are in use): looking at input data for update() and looking at computed heads after update(). Previously, repo tip would be tiprev of the branchcache. With this patch, an obsolete revision can no longer be tiprev. And depending on what way we use for finding tiprev (input data vs computed heads) we'll get a different result. This is relevant when recomputing cache key from cache contents, and may lead to updating cache for obsolete revisions multiple times (not from scratch, because it still would be considered valid for a subset of revisions in the repo).
  • If all commits on a branch are obsolete, the branchcache will include that branch, but the list of heads will be empty (that's why there's now if not heads when recomputing tiprev/tipnode from cache contents). Having an entry for every branch is currently required for notify extension (and test-notify.t to pass), because notify doesn't handle revsets in its subscription config very well and will throw an error if e.g. a branch doesn't exist.
  • Cloning static HTTP repos may try to stat() a non-existent obsstore file. The issue is that we now care about obsolescence during clone, but statichttpvfs doesn't implement a stat method, so a regular vfs.stat() is used, and it assumes that file is local and calls os.stat(). During a clone, we're trying to stat() .hg/store/obsstore, but in static HTTP case we provide a literal URL to the obsstore file on the remote as if it were a local file path. On windows it actually results in a failure in test-static-http.t.

The first issue is going to be addressed in a series dedicated to making sure
branchcache is properly and timely written on disk (it wasn't perfect even
before this patch, but there aren't enough tests to demonstrate that). The
second issue will be addressed in a future patch for notify extension that will
make it not raise an exception if a branch doesn't exist. And the third one was
partially addressed in the previous patch in this series and will be properly
fixed in a future patch when this series is accepted.

filteredhash() grows a keyword argument to make sure that branchcache is also
invalidated when there are new obsolete revisions in its repo view. This way
the on-disk cache format is unchanged and compatible between versions (although
it will obviously be recomputed when switching versions before/after this patch
and the repo has obsolete revisions).

There's one test that uses plain hg up without arguments while updated to a
pruned commit. To make this test pass, simply return current working directory
parent. Later in this series this code will be replaced by what prune command
does: updating to the closest non-obsolete ancestor.

Test changes:

test-branch-change.t: update branch head and cache update message. The head of
default listed in hg heads is changed because revision 2 was rewritten as 7,
and 1 is the closest ancestor on the same branch, so it's the head of default
now.

The cache invalidation message appears now because of the cache hash change,
since we're now accounting for obsolete revisions. Here's some context:

"served.hidden" repo filter means everything is visible (no filtered
revisions), so before this series branch2-served.hidden file would not contain
any cache hash, only revnum and node. Now it also has a hash when there are
obsolete changesets in the repo. The command that the message appears for is
changing branch of 5 and 6, which are now obsolete, so the cache hash changes.

In general, when cache is simply out-of-date, it can be updated using the old
version as a base. But if cache hash differs, then the cache for that
particular repo filter is recomputed (at least with the current
implementation). This is what happens here.

test-obsmarker-template.t: the pull reports 2 heads changed, but after that the
repo correctly sees only 1. The new message could be better, but it's still an
improvement over the previous one where hg pull suggested merging with an
obsolete revision.

test-obsolete.t: we can see these revisions in hg log --hidden, but they
shouldn't be considered heads even with --hidden.

test-rebase-obsolete{,2}.t: there were new heads created previously after
making new orphan changesets, but they weren't detected. Now we are properly
detecting and reporting them.

test-rebase-obsolete4.t: there's only one head now because the other head is
pruned and was falsely reported before.

test-static-http.t: add obsstore to the list of requested files. This file
doesn't exist on the remotes, but clients want it anyway (they get 404). This
is fine, because there are other nonexistent files that clients request, like
.hg/bookmarks or .hg/cache/tags2-served.

Diff Detail

Repository
rHG Mercurial
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

av6 created this revision.Jan 28 2022, 12:38 PM

This patches looks good overall, but I would like to seems a couple of comment expanded for clarity.

mercurial/branchmap.py
360–363

Small nit: we should probably split this four-liner into individual statement.

542

handle it is a bit vague. What about:

We ignored this obsolete changeset earlier, but now that it has non-ignored children, we need to make sure its ancestors are not considered heads. So we mark it for the same post-processing we use for parent in other branches.

mercurial/scmutil.py
362

maybe clarify that we are talking of all filtered and obsolete revision that are ≤ to maxrev ?

369

The use of frozenset on the obsolete set here is unfortunate. As mean a significant computation just to validate the inner cache key.

Please add a comment about this.

I am not sur why the obsrevs are not a frozenset already so we should look into that (outside of this series).

av6 edited the summary of this revision. (Show Details)
av6 updated this revision to Diff 32038.
av6 added inline comments.Feb 3 2022, 7:02 AM
mercurial/branchmap.py
360–363

Yeah, I added this todo item to my follow-up list, because I'd like to update the docstring as well.

mercurial/scmutil.py
369

I'll send a follow-up to make obsolete.getrevs() always return frozensets when this series lands.

Alphare accepted this revision.Feb 3 2022, 11:23 AM
This revision is now accepted and ready to land.Feb 3 2022, 11:23 AM
This revision was automatically updated to reflect the committed changes.