Martin von Zweigbergk <martinvonz@google.com> [Fri, 15 Nov 2019 15:36:09 -0800] rev 43752
dirstate: include explicit matches in match.traversedir calls
The caller should not have to register to get both explicit and
non-explicit matches.
Differential Revision: https://phab.mercurial-scm.org/D7439
Martin von Zweigbergk <martinvonz@google.com> [Fri, 15 Nov 2019 14:47:31 -0800] rev 43751
commit: drop unused "vdirs" argument from repo.checkcommitpatterns()
Differential Revision: https://phab.mercurial-scm.org/D7438
Martin von Zweigbergk <martinvonz@google.com> [Fri, 15 Nov 2019 14:41:00 -0800] rev 43750
commit: rewrite check for `hg ci <path>` being a directory
The matcher API is complicated by match.bad, match.explicitdir, and
match.traversedir. We already have very few users of
match.explicitdir. By rewriting this check we get close to being able
to remove match.explicitdir.
This may make the check slower, but I think that will be very
marginal.
Disclosure: I actually wrote this patch to solve a bug we've seen with
an internal extension. The internal extension overrides the dirstate
walk to only walk the files that our FUSE tells us are modified. That
led to "vdirs" not getting populated as this code expected. I have
wanted to get rid of match.explicitdir for a very long time, though.
Differential Revision: https://phab.mercurial-scm.org/D7437
Valentin Gatien-Baron <valentin.gatienbaron@gmail.com> [Mon, 18 Nov 2019 20:10:38 -0800] rev 43749
lock: fix race in lock-breaking code
With low frequency, I see hg pulls fail with output like:
abort: no such file or directory: .hg/store/lock
I think what happens is, in lock.py, in:
def _testlock(self, locker):
if not self._lockshouldbebroken(locker):
return locker
# if locker dead, break lock. must do this with another lock
# held, or can race and break valid lock.
try:
with lock(self.vfs, self.f + b'.break', timeout=0):
self.vfs.unlink(self.f)
except error.LockError:
return locker
if a lock is breakable on disk, and two hg processes concurrently get
to the "if locker dead" comment, a possible interleaving is: process1
finishes executing the function and then process2 finishes executing
the function. If that happens, process2 will either get ENOENT in
self.vfs.unlink (resulting in the spurious failure above), or break a
valid lock and potentially cause repository corruption.
The fix is simple enough: make sure the lock is breakable _inside_ the
critical section, because only then can we know that no other process
can invalidate our knowledge on the lock on disk.
I don't think there are tests for this. I've tested this manually
with:
diff --git a/mercurial/lock.py b/mercurial/lock.py
--- a/mercurial/lock.py
+++ b/mercurial/lock.py
@@ -351,6 +351,8 @@ class lock(object):
if not self._lockshouldbebroken(locker):
return locker
+ import random
+ time.sleep(1. + random.random())
# if locker dead, break lock. must do this with another lock
# held, or can race and break valid lock.
try:
@@ -358,6 +360,7 @@ class lock(object):
self.vfs.unlink(self.f)
except error.LockError:
return locker
+ time.sleep(1)
def testlock(self):
"""return id of locker if lock is valid, else None.
and I see this change of behavior before/after this commit:
$ $hg init repo
$ cd repo
$ ln -s $HOSTNAME/effffffc:987654321 .hg/wlock
$ touch a
$ $hg commit -Am_ & $hg commit -Am _; wait
-abort: No such file or directory: '/tmp/repo/.hg/wlock'
adding a
+warning: ignoring unknown working parent 679a8959a8ca!
+nothing changed
Differential Revision: https://phab.mercurial-scm.org/D7199
Valentin Gatien-Baron <valentin.gatienbaron@gmail.com> [Fri, 01 Nov 2019 19:59:07 -0400] rev 43748
lock: refactor in preparation for next commit
Differential Revision: https://phab.mercurial-scm.org/D7198
Augie Fackler <augie@google.com> [Fri, 15 Nov 2019 11:30:33 -0500] rev 43747
extensions: suppress a pytype failure due to a typeshed bug
Bug filed upstream, suppress the failure here so we can move on.
Differential Revision: https://phab.mercurial-scm.org/D7410
Augie Fackler <augie@google.com> [Thu, 14 Nov 2019 15:49:21 -0500] rev 43746
dispatch: add some assertions to give pytype a helping hand
Differential Revision: https://phab.mercurial-scm.org/D7409
Augie Fackler <augie@google.com> [Thu, 14 Nov 2019 15:49:01 -0500] rev 43745
extensions: hide two confusing import statements from pytype
Differential Revision: https://phab.mercurial-scm.org/D7408