age-out watches about watchman

[sunshowers]

There's no refcounting for watches, though that wouldn't be a bad feature request.

[wez]

I've been thinking about adding an aging feature for watches. The idea is that you would specify a global configuration with the idle parameters. If the watch has no registered triggers and no connected subscribers, and has not had any queries and has not processed any change notifications for the specified amount of time, we could have watchman automatically cancel the watch.

Meanwhile, don't watch-del unless you know that you own the watch. The watch can be manually cancelled by the user, and will be automatically cancelled when the dir is removed.

[amasad]

Is there a way to know if I completely own the watch?
(maybe do watch-list before watching?)

[wez]

No, there's not a great way to know whether another tool might be interested and actively watching. Since we allow non-persistent polling (eg: you don't need to maintain a socket connection between queries), there isn't a way to know for sure who might want the watch to continue existing, which is why a solution to this is most likely to be implemented by automatically aging out watches as I mentioned above.

[amasad]

Yes, this seems like the best solution. However, this isn't really an issue right now, I'll let you know if it becomes a pressing one.

[wez]

I think the new watch-project stuff obviates the need for this. I'm going to close this issue; we can revisit if needed in the future.

[stefanpenner]

@wez I would like to still plead my case for a watcher decay of some reasonable half-life.

I still need to update ember-cli to take better advantage of watchman, but even with that (and watch-project) I believe a watcher decay would make watchman a much better citizen.

In my developer workflow it is not uncommon to for me to check out various projects a day, each one then indefinitely leaks watchers.

Why would I checkout another project?

• preview an add-on demo
• fix a bug in an add-on
• code-review
• creating a new add-on
• creating a new app
• creating a new reproduction of an error scenario

Theoretically solutions:

• conventionalize a shared root for all these activities, and watch the root

  unfortunately, this will likely be difficult to conventionalize across the larger OSS community

[wez]

OK, let's re-open under a different name

[wez]

We have https://reviews.facebook.net/D37701 in review as a possible implementation of this feature

[wez]

This has landed in master and will be part of Watchman 3.7 that we're cutting this week

[stefanpenner]

nice, thanks @wez