We've been seeing "Task X took Y seconds" warnings in our tests for a
long time, especially on Windows. Running git commands synchronously
blocks other tasks from running, like display redrawing. It's bad
practice in an async program.
One of the barriers to async-ifying the cache code earlier was that many
commands relied on having exclusive ownership of the index file while
they were running. For example, 1) read a tree into the index, 2) merge
another tree into some subdirectory, 3) write out the result. If any
other git commands ran in the middle of that, it would screw up the
result. So we need to rewrite every cache function to use its own
temporary index file, if we want them to run in parallel.
The reason I'm finally getting around to this now, is that I'm trying to
reduce the number of git commands that run in a no-op sync. One of the
optimizations I'm going to want to do, is to reuse the index file from
the last sync, so that we don't need a `read-tree` and an `update-index`
just to set us up for `diff-files`. But the plumbing to do that right is
pretty much the same as what we should be doing to run every git command
with its own index anyway. So let's just bite the bullet and do that
now, and then reusing index files will be easy after that.
Summary:
The new Scope class takes over target parsing from `imports.py`, and it
takes over holding the dictionaries of defined modules and rules from
`Runtime`. The target parsing methods it provides are capable of
splitting up a scoped name (i.e. `a.b.c`) and traversing the containing
modules. This depends on a `Module.get_scope` method that doesn't exist
yet, but we mock it out for the test.
This is the last major piece of groundwork we need to lay before we can
start enabling recursive features.
Right now we stick `imports` onto `Scope`, just because it's parsed at
the same time as `modules` and `rules`. That doesn't feel quite right,
and I'm planning to clean it up in subsequent diffs.
Test Plan:
A new unit test that mocks out modules, rules, and scope creation. We
only directly test `parse_target`, but that depends on most of the rest
of the functionality in `Scope`.
Reviewers: sean
Reviewed By: sean
Differential Revision: https://phabricator.buildinspace.com/D174
Jack O'Connor