On Sat, 25 Apr 2015 03:03:50 +0200, Andy Bradford
<amb-fos...@bradfords.org> wrote:
Thus said Richard Hipp on Sat, 18 Apr 2015 09:53:53 -0400:
Proposed solutions include denying the ability to commit or push a
fork. But doesn't that just make the problem worse?
Yes, I think it does make it worse; this is not a practical approach in
my opinion. I think it better to have the fork and receive a warning
about it, or see it in the timeline than deny it.
We've already established that users are in the habit of ignoring
scary fork warnings.
If they've seen them. They may not be seeing them due to infrastructure.
E.g. User1 syncs to site1.dom and User2 syncs to site2.dom, where there
is a 10 minute synchronization delay between site1.dom and site2.dom. If
User1 and User2 checkin against the same leaf within that 10 minute
window, currently neither will get a warning about forks.
Other proposed changes include more frequent nagging about forks. The
issue is less clear-cut, but I still worry that it might contribute to
warning fatigue. I go by the motto that you should always distrust any
computer program that thinks it knows more than you do. Constant
nagging about forks seems to move Fossil in the direction of programs
that I would not trust. This is not to say that there shouldn't be
warnings, but there needs to be balance.
I too was worried about warning fatigue. It should warn as little as
possible. How to achieve that, while also providing more advanced
warning to those who want it is a difficult challenge.
I also am not fond of computer programs that behave as if they know more
than I do; this is one of the reasons why I prefer Fossil over Git. :-)
Regarding the balance for fork warnings, where there seems to be a high
volume of forks, will additional notification help prevent the forks?
Probably not because a fork is something that has already occurred, but
it might help them be resolved more quickly as they will be detected
sooner. Specifically, I'm talking about the kind of fork that happens
silently that goes undetected for whatever reason. For a project where
fork volume is low, will more notifications be a hindrance?
I've sought to create a balance in the sync-forkwarn branch between the
frequency of the nag and when to nag. For example, it will not nag on a
clone---what's the point? It also won't nag if the artifact received is
part of a fork previously existing in the clone (again, no need to nag
continuously about a checkin against a fork that should already be
known). But it will nag if you receive an artifact that has caused a new
fork in your clone. The first person to generate a fork will be the one
to get the first notification, and if they address it, no other people
will be notified.
Are these changes reasonable? Does it fit the parsimoniousness of
Fossil? Or is it too much?
How many forks in Fossil were done intentionally (e.g. with
--allow-fork)? How many were unintentional and would have been resolved
more quickly had a warning been issued at the time the fork was
synchronized?
I believe having these warnings would be good and would opt for making a
"field test" whether it is well accepted or not in the fossil users
community. regarding 'notification overload'. I always found and still
find part of the regular fossil output to verbose.
e.g. doing a `fossil up' when already in sync with the server (with
autosync on) one gets 8 lines of output the only two being really relevant
being the one confirming that pulling is under way and the 'changes' linen
stating that nothing has changed.
and probably the average user will not care how many artifacts have been
sent or received but only would like to see some sort of progress feedback
I presume. what I mean is: at a few places there might be a suboptimal
signal to noise ratio in the default output and the relevant ones like
failure to sync or detected forks should stand out sufficiently.
another idea: maybe `fossil info' could also include a warning line if
there are any forks at present?
thx/j
Thanks,
Andy
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
