Thu, 21 Nov 2019 14:28:28 -0500 patch: fix a str + bytes issue in an exception handler stable
Matt Harbison <matt_harbison@yahoo.com> [Thu, 21 Nov 2019 14:28:28 -0500] rev 43723
patch: fix a str + bytes issue in an exception handler Flagged by pytype. Differential Revision: https://phab.mercurial-scm.org/D7466
Wed, 20 Nov 2019 08:11:21 -0800 py3: wrap a __func__ in sysbytes() before logging as bytes stable
Martin von Zweigbergk <martinvonz@google.com> [Wed, 20 Nov 2019 08:11:21 -0800] rev 43722
py3: wrap a __func__ in sysbytes() before logging as bytes Differential Revision: https://phab.mercurial-scm.org/D7461
Wed, 20 Nov 2019 19:16:11 -0800 py3: make doc strings containing deprecated '\.' escape sequence raw strings stable
Daniel Ploch <dploch@google.com> [Wed, 20 Nov 2019 19:16:11 -0800] rev 43721
py3: make doc strings containing deprecated '\.' escape sequence raw strings Differential Revision: https://phab.mercurial-scm.org/D7462
Tue, 19 Nov 2019 14:59:23 -0500 shelve: add the missing `create` parameter to the bundlerepo constructor stable
Matt Harbison <matt_harbison@yahoo.com> [Tue, 19 Nov 2019 14:59:23 -0500] rev 43720
shelve: add the missing `create` parameter to the bundlerepo constructor Caught by pytype. Differential Revision: https://phab.mercurial-scm.org/D7458
Tue, 19 Nov 2019 14:36:22 -0500 shelve: fix a missing variable in the exception handler for delete stable
Matt Harbison <matt_harbison@yahoo.com> [Tue, 19 Nov 2019 14:36:22 -0500] rev 43719
shelve: fix a missing variable in the exception handler for delete Caught by pytype. I haven't paid much attention to the progress of this extension, but I *think* this was the intent. Differential Revision: https://phab.mercurial-scm.org/D7457
Fri, 15 Nov 2019 15:58:56 -0500 hgweb: add diffs to the json changeset template
Jordi Gutiérrez Hermoso <jordigh@octave.org> [Fri, 15 Nov 2019 15:58:56 -0500] rev 43718
hgweb: add diffs to the json changeset template While it's possible to get the diff for each file individually via an obscure url that I'm not even sure is documented, (e.g. diff/{rev}/{filename}?style=json ), it is more convenient to provide the full diff from the changeset view. This is already normally computed for other non-JSON templates, so it seems like an oversight to omit it for the JSON one. The output format is a bit unwieldy but it's consistent with the existing format output by the aforementioned obscure url.
Fri, 15 Nov 2019 15:56:25 -0500 hgweb: add files to the json changeset template
Jordi Gutiérrez Hermoso <jordigh@octave.org> [Fri, 15 Nov 2019 15:56:25 -0500] rev 43717
hgweb: add files to the json changeset template As far as I can tell, it's currently impossible via JSON to figure out what files are touched by a particular revision. Reusing the filenodelink and filenolink templates from the other hgweb templates should provide this information.
Fri, 15 Nov 2019 16:02:01 -0500 hgweb: add a status property to file list context
Jordi Gutiérrez Hermoso <jordigh@octave.org> [Fri, 15 Nov 2019 16:02:01 -0500] rev 43716
hgweb: add a status property to file list context The web templates merely indicate if files touched by this revision are in the commit or not, i.e. if they are removed. It would be helpful to have more context and also indicate whether the files are added, modified, or removed.
Fri, 15 Nov 2019 14:50:13 -0800 match: remove explicitdir attribute
Martin von Zweigbergk <martinvonz@google.com> [Fri, 15 Nov 2019 14:50:13 -0800] rev 43715
match: remove explicitdir attribute No one sets it or reads it anymore. Differential Revision: https://phab.mercurial-scm.org/D7441
Fri, 15 Nov 2019 15:36:14 -0800 dirstate: stop caring about match.explicitdir
Martin von Zweigbergk <martinvonz@google.com> [Fri, 15 Nov 2019 15:36:14 -0800] rev 43714
dirstate: stop caring about match.explicitdir No one passes it in anymore. Differential Revision: https://phab.mercurial-scm.org/D7440
Fri, 15 Nov 2019 15:36:09 -0800 dirstate: include explicit matches in match.traversedir calls
Martin von Zweigbergk <martinvonz@google.com> [Fri, 15 Nov 2019 15:36:09 -0800] rev 43713
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
Fri, 15 Nov 2019 14:47:31 -0800 commit: drop unused "vdirs" argument from repo.checkcommitpatterns()
Martin von Zweigbergk <martinvonz@google.com> [Fri, 15 Nov 2019 14:47:31 -0800] rev 43712
commit: drop unused "vdirs" argument from repo.checkcommitpatterns() Differential Revision: https://phab.mercurial-scm.org/D7438
Fri, 15 Nov 2019 14:41:00 -0800 commit: rewrite check for `hg ci <path>` being a directory
Martin von Zweigbergk <martinvonz@google.com> [Fri, 15 Nov 2019 14:41:00 -0800] rev 43711
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
Tue, 19 Nov 2019 11:59:43 +0100 py3: use pycompat.bytestr() instead of pycompat.sysstr() stable
Manuel Jacob <me@manueljacob.de> [Tue, 19 Nov 2019 11:59:43 +0100] rev 43710
py3: use pycompat.bytestr() instead of pycompat.sysstr() pycompat.sysstr() doesn’t work because it doesn’t accept arguments of type `type` and returns a unicode object on Python3, while the format string wants a bytes-like object.
Mon, 18 Nov 2019 20:10:38 -0800 lock: fix race in lock-breaking code
Valentin Gatien-Baron <valentin.gatienbaron@gmail.com> [Mon, 18 Nov 2019 20:10:38 -0800] rev 43709
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
Fri, 01 Nov 2019 19:59:07 -0400 lock: refactor in preparation for next commit
Valentin Gatien-Baron <valentin.gatienbaron@gmail.com> [Fri, 01 Nov 2019 19:59:07 -0400] rev 43708
lock: refactor in preparation for next commit Differential Revision: https://phab.mercurial-scm.org/D7198
Fri, 15 Nov 2019 11:30:33 -0500 extensions: suppress a pytype failure due to a typeshed bug
Augie Fackler <augie@google.com> [Fri, 15 Nov 2019 11:30:33 -0500] rev 43707
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
Thu, 14 Nov 2019 15:49:21 -0500 dispatch: add some assertions to give pytype a helping hand
Augie Fackler <augie@google.com> [Thu, 14 Nov 2019 15:49:21 -0500] rev 43706
dispatch: add some assertions to give pytype a helping hand Differential Revision: https://phab.mercurial-scm.org/D7409
Thu, 14 Nov 2019 15:49:01 -0500 extensions: hide two confusing import statements from pytype
Augie Fackler <augie@google.com> [Thu, 14 Nov 2019 15:49:01 -0500] rev 43705
extensions: hide two confusing import statements from pytype Differential Revision: https://phab.mercurial-scm.org/D7408
Thu, 14 Nov 2019 13:27:57 -0500 debugcommands: add assertions to convince pytype peer is not None
Augie Fackler <augie@google.com> [Thu, 14 Nov 2019 13:27:57 -0500] rev 43704
debugcommands: add assertions to convince pytype peer is not None This function is moderately annoyingly defined, and peer is set up iff we're not in raw-proto mode. That's fine, but it confuses pytype. Adding these assertions is a low-overhead way to convince pytype we're doing reasonable things. Differential Revision: https://phab.mercurial-scm.org/D7407
Wed, 13 Nov 2019 22:35:15 -0500 debugcommands: suppress import errors for pytype
Augie Fackler <augie@google.com> [Wed, 13 Nov 2019 22:35:15 -0500] rev 43703
debugcommands: suppress import errors for pytype Differential Revision: https://phab.mercurial-scm.org/D7385
Wed, 13 Nov 2019 22:22:49 -0500 state: add a pytype annotation
Augie Fackler <augie@google.com> [Wed, 13 Nov 2019 22:22:49 -0500] rev 43702
state: add a pytype annotation Differential Revision: https://phab.mercurial-scm.org/D7383
Wed, 13 Nov 2019 22:22:31 -0500 logcmdutil: add a type annotation
Augie Fackler <augie@google.com> [Wed, 13 Nov 2019 22:22:31 -0500] rev 43701
logcmdutil: add a type annotation This wasn't actually required in the end, as there was a real bug found by pytype, but the annotation helped me figure that out. We can drop this patch if that's the preference. Differential Revision: https://phab.mercurial-scm.org/D7382
Wed, 13 Nov 2019 22:21:38 -0500 cmdutil: add a pytype annotation to help out some callsites
Augie Fackler <augie@google.com> [Wed, 13 Nov 2019 22:21:38 -0500] rev 43700
cmdutil: add a pytype annotation to help out some callsites I think we could constrain the values here more than Any, but this lets us move forward with typechecking commands.py. Differential Revision: https://phab.mercurial-scm.org/D7381
Tue, 12 Nov 2019 17:47:42 -0500 hghave: add a check for the `xz` compression utility
Matt Harbison <matt_harbison@yahoo.com> [Tue, 12 Nov 2019 17:47:42 -0500] rev 43699
hghave: add a check for the `xz` compression utility This isn't install by default on Mac, which causes a test failure. The logic for avoiding the command is a little goofy, but nested `#if` isn't supported, and it still seems worth running the hg command to see if anything explodes. With this, the py3 tests run (almost) cleanly on 10.14.6: # Ran 835 tests, 58 skipped, 1 failed. Alas, the mac-packaging test is skipped because it's slow. The failure here is in test-releasenotes-merging.t, complaining about not being able to import the `fuzzywuzzy` module. I have it installed on py3 (thus the test isn't skipped), but not on py2. So there must be some unintended cross pollination here when running `hg` commands. Differential Revision: https://phab.mercurial-scm.org/D7374
Thu, 14 Nov 2019 22:31:21 -0800 py3: use '%d' for formatting a revnum in `hg co --date` code
Martin von Zweigbergk <martinvonz@google.com> [Thu, 14 Nov 2019 22:31:21 -0800] rev 43698
py3: use '%d' for formatting a revnum in `hg co --date` code Differential Revision: https://phab.mercurial-scm.org/D7429
Mon, 18 Nov 2019 17:37:59 +0100 py3: send bytes from Rust-created warning patterns
Raphaël Gomès <rgomes@octobus.net> [Mon, 18 Nov 2019 17:37:59 +0100] rev 43697
py3: send bytes from Rust-created warning patterns Python code expects bytes in both Python 2 and Python 3, so we should send bytes. Differential Revision: https://phab.mercurial-scm.org/D7454
Mon, 18 Nov 2019 17:34:44 +0100 py3: pass bytes to `configint` and `configbool`
Raphaël Gomès <rgomes@octobus.net> [Mon, 18 Nov 2019 17:34:44 +0100] rev 43696
py3: pass bytes to `configint` and `configbool` Both functions require bytes, even in Python 3. Differential Revision: https://phab.mercurial-scm.org/D7453
Fri, 15 Nov 2019 10:16:27 -0800 templates: make {indent("", " ")} be empty
Martin von Zweigbergk <martinvonz@google.com> [Fri, 15 Nov 2019 10:16:27 -0800] rev 43695
templates: make {indent("", " ")} be empty indent() is documented to indent all non-empty lines, but it made an exception for the first line, which always got indented. I also made indent() not indent the first line even if an indent override was given for the first line. I think that is what one would usually want. Differential Revision: https://phab.mercurial-scm.org/D7432
Fri, 15 Nov 2019 10:16:22 -0800 tests: document behavior of indent() with empty first line
Martin von Zweigbergk <martinvonz@google.com> [Fri, 15 Nov 2019 10:16:22 -0800] rev 43694
tests: document behavior of indent() with empty first line indent() is documented to indent all non-empty lines, but it still indents the first line even if it's empty. Let's have tests for that. Differential Revision: https://phab.mercurial-scm.org/D7431
(0) -30000 -10000 -3000 -1000 -300 -100 -50 -30 +30 +50 +100 +300 +1000 +3000 tip