This prepares us to perform a diff against the previous snapshot before installing a new worktree snapshot on the foreground thread.
Co-Authored-By: Max Brunsfeld <maxbrunsfeld@gmail.com>
We only needed this when we relied on inodes for file identity, which we no longer attempt to do.
Co-Authored-By: Max Brunsfeld <maxbrunsfeld@gmail.com>
For now this enum only contains a `Local` variant, but the next step is
to add a `Remote` variant that will be constructed when joining a remote
worktree.
* Remove `FromClient`/`FromServer` distinction.
* Remove `subscribe` concept - clients will need to handle
unprompted messages from the server.
Co-Authored-By: Nathan Sobo <nathan@zed.dev>
I am not sure I have caught all the examples of this, but in general
I think we always want to perform a `flush_fs_events` as opposed to
`next_scan_complete` when doing synchronous I/O. Indeed, the file
system may inform us about the events caused by the just-performed
I/O over multiple batches, and `next_scan_complete` may return
before seeing all of them.
Note that this also removes a few assertions which were ensuring
that, on start, a worktree's file handle wouldn't know its deleted
status, even if the file didn't exist for sure on disk. However,
now that `file` is an async API, it's possible that by the time the
`FileHandle` is resolved, `Worktree` has already completed scanning.
We test a similar behavior further along in the test where those
assertions were removed, so it felt okay to proceed without them.
Now when you call spawn in various context, you pass an FnOnce that is called with an AsyncAppContext and returns a static future. This allows you to write async code similar to how our tests work, borrowing the guts of the AsyncAppContext when needed to interact, but using normal async await semantics instead of callbacks.
Co-Authored-By: Max Brunsfeld <maxbrunsfeld@gmail.com>
Sometimes the scan state could change so quickly that the consumer
wouldn't notice that it ever went to a scanning state before going back
to an idle state, hence never resolving.
Co-Authored-By: Nathan Sobo <nathan@zed.dev>
* Don't consider files deleted if they just haven't been scanned yet.
* Consider a buffer dirty if its file has been deleted.
Co-Authored-By: Nathan Sobo <nathan@zed.dev>
Antonio Scandurra
Nathan SoboandMax Brunsfeld
