[Unison-hackers] Make "watch = false" the default

[Benjamin Pierce]

This matches my (somewhat hazy :-) recollection.

       - Benjamin

On Sat, Jun 5, 2021 at 3:16 PM Tõivo Leedjärv <toivol at gmail.com> wrote:

> The "watch" preference defaulting to "true" has caused some issues
> ([1] [2] and some others) to users who may not even know they are
> running with the watcher enabled. With some of these bugs unresolved
> and watcher semantics still somewhat confusing and limited (see
> below), I'd like to initiate a discussion to make "watch" preference
> default to "false". This default can then be revised again once
> critical bugs are fixed and semantics extended or better documented.
>
> The exact proposal is this:
> 1. "watch = false" becomes the default for everyone.
> 2. "watch" is automatically flipped to "true" if "-repeat watch" is
> specified.
>
> Reasoning for point 2 is simple: "-repeat watch" requires "watch =
> true" and specifying "repeat" is the only request the user should make
> or be forced to know about.
>
> Reasoning for point 1 can now completely exclude scenarios where the
> user has specified "-repeat watch". It is my assumption that using
> "watch = true" without "-repeat watch" is currently almost always a
> result of the defaults, not of user intention. There is no clear
> documentation of the "watch" preference for users to base their
> intentions on.
>
> I have investigated the code a bit and my current (possibly limited or
> incorrect) understanding is that a) the "watch" preference without
> "-repeat watch" is only leveraged by the GUIs; and b) the effect of
> the "watch = true" without "-repeat watch" is limited to non-existent.
> Users (in general, but even more so when using the text UI) are not
> getting any benefits from the default preference, yet they are exposed
> to potential bugs.
>
> The limited to non-existent effect claim is based on my understanding
> that input from the fsmonitor process is used solely to filter the
> (static) list of paths Unison is going to scan. The list of paths to
> scan itself does not come from fsmonitor process, it is the list of
> paths from the profile. For example, if the user has not specified any
> explicit paths then the paths to scan are the roots. Here, the effect
> from "watch = true" is binary, either not scan the root (no changes
> reported by fsmonitor) or scan the entire root (any change reported by
> fsmonitor). This may sound like somewhat of a benefit but it has to be
> put in context: first, it currently works only in GUIs (for example by
> clicking the "Rescan" button; but not when specifying "-repeat N" on
> command line), and second, re-scanning even big roots tends to be very
> (even extremely) fast (assuming much has been cached). It may be
> slower on Windows (I have no empirical data) but again, the decision
> not to scan is made only if fsmonitor has not reported any changes at
> all.
>
> Please do correct me if my understanding is incorrect at any point.
>
> At the moment, the fsmonitor binary is not packaged on Windows due to [2].
>
> [1] https://github.com/bcpierce00/unison/issues/329#issuecomment-708633505
> [2] https://github.com/bcpierce00/unison/pull/493#issuecomment-823419018
> _______________________________________________
> Unison-hackers mailing list
> Unison-hackers at LISTS.SEAS.UPENN.EDU
> https://LISTS.SEAS.UPENN.EDU/mailman/listinfo/unison-hackers
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://LISTS.SEAS.UPENN.EDU/pipermail/unison-hackers/attachments/20210606/0dae15e3/attachment-0001.htm>