Fri, 16 Aug 2024 18:02:32 -0400 dirstate: remove the interface decorator to help pytype
Matt Harbison <matt_harbison@yahoo.com> [Fri, 16 Aug 2024 18:02:32 -0400] rev 51808
dirstate: remove the interface decorator to help pytype This is the same change that was made for some of the manifest classes in 3e9a660b074a. Note that `dirstate` is still inferred as `Any`, but at least we have `DirState` with all of the expected attributes.
Fri, 16 Aug 2024 17:58:17 -0400 largefiles: sync up `largefilesdirstate` methods with `dirstate` base class
Matt Harbison <matt_harbison@yahoo.com> [Fri, 16 Aug 2024 17:58:17 -0400] rev 51807
largefiles: sync up `largefilesdirstate` methods with `dirstate` base class As it currently stands, pytype infers the `dirstate` class (and anything else decorated with `@interfaceutil.implementer`) as `Any`. When that is worked around, it suddenly noticed that most of these methods don't exist in the `dirstate` class anymore. Since they only called into the missing methods and there's no test failures, we can assume these are never called, and they can be dropped. In addition, PyCharm flagged `set_tracked()` and `_ignore()` as not overriding a superclass method with the same arguments. The missing default parameter for the former was the obvious issue. I'm guessing that the latter was named wrong because while there is `_ignore()` in the base class, it takes no arguments and returns a matcher. The `_ignorefiles()` superclass method also takes no args, and returns a list of bytes. The `_ignorefileandline()` superclass method DOES take a file, but returns a tuple. Therefore, the closest match is `_dirignore()`, which takes a file AND returns a bool. No idea why this needs to be overridden though.
Fri, 16 Aug 2024 11:12:19 +0100 sparse: reliably avoid writing to store without a lock
Arseniy Alekseyev <aalekseyev@janestreet.com> [Fri, 16 Aug 2024 11:12:19 +0100] rev 51806
sparse: reliably avoid writing to store without a lock With the code as written before this patch we can still end up writing to store in `debugsparse`. Obviously we'll write to it if by accident a store requirement is modified, but more importantly we write to it if another concurrent transaction modifies the requirements file on disk. We can't rule this out since we're not holding the store lock, so it's better to explicitly pass a permission to write instead of inferring it based on file contents.
Thu, 15 Aug 2024 13:52:14 +0100 debugsparse: stop taking the store lock
Arseniy Alekseyev <aalekseyev@janestreet.com> [Thu, 15 Aug 2024 13:52:14 +0100] rev 51805
debugsparse: stop taking the store lock debugsparse is a workspace-only opperation, or it better be workspace-only. Let's make it to stop taking the store lock.
(0) -30000 -10000 -3000 -1000 -300 -100 -30 -10 -4 +4 +10 +30 +100 +300 tip