comparison mercurial/scmutil.py @ 48687:f8f2ecdde4b5

branchmap: skip obsolete revisions while computing heads 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. Differential Revision: https://phab.mercurial-scm.org/D12097
author Anton Shestakov <av6@dwimlabs.net>
date Fri, 07 Jan 2022 11:53:23 +0300
parents c51408b92b88
children c7e675848027
comparison
equal deleted inserted replaced
48686:4507bc001365 48687:f8f2ecdde4b5
347 self._ui.warn(_(b"warning: %s\n") % msg) 347 self._ui.warn(_(b"warning: %s\n") % msg)
348 self._loweredfiles.add(fl) 348 self._loweredfiles.add(fl)
349 self._newfiles.add(f) 349 self._newfiles.add(f)
350 350
351 351
352 def filteredhash(repo, maxrev): 352 def filteredhash(repo, maxrev, needobsolete=False):
353 """build hash of filtered revisions in the current repoview. 353 """build hash of filtered revisions in the current repoview.
354 354
355 Multiple caches perform up-to-date validation by checking that the 355 Multiple caches perform up-to-date validation by checking that the
356 tiprev and tipnode stored in the cache file match the current repository. 356 tiprev and tipnode stored in the cache file match the current repository.
357 However, this is not sufficient for validating repoviews because the set 357 However, this is not sufficient for validating repoviews because the set
358 of revisions in the view may change without the repository tiprev and 358 of revisions in the view may change without the repository tiprev and
359 tipnode changing. 359 tipnode changing.
360 360
361 This function hashes all the revs filtered from the view and returns 361 This function hashes all the revs filtered from the view (and, optionally,
362 that SHA-1 digest. 362 all obsolete revs) up to maxrev and returns that SHA-1 digest.
363 """ 363 """
364 cl = repo.changelog 364 cl = repo.changelog
365 if not cl.filteredrevs: 365 if needobsolete:
366 return None 366 obsrevs = obsolete.getrevs(repo, b'obsolete')
367 key = cl._filteredrevs_hashcache.get(maxrev) 367 if not cl.filteredrevs and not obsrevs:
368 if not key: 368 return None
369 revs = sorted(r for r in cl.filteredrevs if r <= maxrev) 369 # TODO: obsrevs should be a frozenset, but right now obsolete.getrevs()
370 # may return a set, which is not a hashable type.
371 key = (maxrev, hash(cl.filteredrevs), hash(frozenset(obsrevs)))
372 else:
373 if not cl.filteredrevs:
374 return None
375 key = maxrev
376 obsrevs = frozenset()
377
378 result = cl._filteredrevs_hashcache.get(key)
379 if not result:
380 revs = sorted(r for r in cl.filteredrevs | obsrevs if r <= maxrev)
370 if revs: 381 if revs:
371 s = hashutil.sha1() 382 s = hashutil.sha1()
372 for rev in revs: 383 for rev in revs:
373 s.update(b'%d;' % rev) 384 s.update(b'%d;' % rev)
374 key = s.digest() 385 result = s.digest()
375 cl._filteredrevs_hashcache[maxrev] = key 386 cl._filteredrevs_hashcache[key] = result
376 return key 387 return result
377 388
378 389
379 def walkrepos(path, followsym=False, seen_dirs=None, recurse=False): 390 def walkrepos(path, followsym=False, seen_dirs=None, recurse=False):
380 """yield every hg repository under path, always recursively. 391 """yield every hg repository under path, always recursively.
381 The recurse flag will only control recursion into repo working dirs""" 392 The recurse flag will only control recursion into repo working dirs"""