Avoid file locks by being smarter about when we try to rebuild our information

[anaisbetts]

On Windows, file locks are enforced, meaning that if we try to access files right after they have been written to, it is highly likely that we'll run into locking issues - either by our own app, Antivirus, or by the application that caused the change (many IDEs and editors are also doing similar operations because they also support Git)

Furthermore even on platforms that we don't have to worry about locking, being aggressive about responding to file change notifications means that we will end up looking at a bunch of files that are changing in-progress, especially with projects that do large changes all at once (i.e. Gradle sync in Android projects)

The Plan - scan when we need it, and when the notifications are quiet

So instead of maintaining a very low debounce threshold of 100ms, instead we are going to make the debounce threshold much, much higher - this timeout will only fire when the project folder is effectively constantly changing. In addition however, we're going to manually flush notifications in two scenarios:

• If the files in the project are no longer changing - if change notifications have not come in for longer than 1500ms, we will flush any pending change notifications. This gets us out of the way of other tools while still keeping us relatively up-to-date

• When the window gets focus, flush immediately - this is where we definitely need the most up-to-date information, because the user is about to do something

TODO:

• Write a version of notify-debouncer-full that allows us to hint when we should flush changes
• Plumb this through gitbutler-watcher
• Flush on window focus
• Flush on system idle

Discussion at https://discord.com/channels/1060193121130000425/1204524097241878629/1237028051800297543

[krlvi]

Hey! A had a few questions:

if change notifications have not come in for longer than 1500ms

Does this mean that in most cases (while no build etc is running) this will be the time until the app can update it's state after a file change? Or is this threshold applied only to subsequent events?
If it's applied to all events, I wonder if a lower value (e.g. 700ms) could also achieve avoiding of the locking, while having a more 'responsive' feel.

Thinking of the scenario where the app is on a separate monitor but not in focus

[anaisbetts]

If it's applied to all events, I wonder if a lower value (e.g. 700ms) could also achieve avoiding of the locking, while having a more 'responsive' feel.

We can tweak this number of course, but I wouldn't worry as much about the multiple-monitor scenario - they still won't really need this information until they go to commit, in which case they'll give the window focus and it'll update

[Caleb-T-Owens]

@krlvi The version control tab in VSCode often takes a second to update - and that is on the same screen! Especially with the focus always performing a flush, if it performs better with the 1.5s debounce, I don't think we ought to worry too much.