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? Thanks, Andy -- TAI64 timestamp: 40000000553ae819 _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
