Re: On making times=true the default

This is a summary of my thoughts based on your ideas so far.

I have to say that I am very much unconvinced by the idea of
automatically or silently propagating some updates. I don't think I
can be convinced on this.

I do agree that for existing users the change of default must come
(quoting) "with almost no difficulty and reasonable effort." but my
view on what is reasonable is very much towards the "effortless" end
of the scale. We need to take care of all users and the more casual
the user the less difficulty and effort they should face.

We have to acknowledge that it's possible that (the vast?) majority of
users don't even upgrade conciously. Rather, it's done for them by
their package manager. This means that any action the user has to
actively initiate before, during or after the upgrade is out of the
question. Manual actions like this are also not an option for those
running in batch mode.

So I return to my original proposal: to not change the 'times' default
for existing archives. There is no reason to force something
automatically. Yet, at least. There is always the option of returning
to this decision in a future version.

For newly created and regenerated archives a smooth path over mtime
conflicts is still needed. I don't fully like the idea of times=repair
as presented, for a few reasons. First, as I already wrote above, the
silent/automatic nature of it is not acceptable to me. Also, calling
it "repair" and having to flip it on and off for a single run is
conceptually misleading, I think. Instead, I'd like to come back to
the times=auto idea with automatic conflict resolution. For new
archives, Unison should detect mtime-only conflicts. In interactive
mode, the user should be informed of what is going on and explained
about the automatic conflict resolution. Should they not want it, they
can manually change individual propagation choices or quit and
explicitly set times=true (or times=false). In batch mode times=auto
would still work as times=repair except the list of files would be
displayed/logged as usual.

Finally, coming to the FAT issue. We basically have two options: 1)
not sync times on FAT by default; 2) automatically cater for DST
changes. I don't think option 1 is the right way to go (but I can be
convinced otherwise if it turns out that there are problems in
practice). FAT is perfectly capable of syncing times. The only major
trouble comes when the time zone changes. Even if option 1 would be
the solution, we'd still have to implement file system type detection
(having done some research, this shouldn't be _too_ difficult). But if
we already have file system type detection, going with option 2
becomes the natural choice. More so because, until recently, Unison
did automatically cater for DST changes.