[Default] On Sat, 18 Apr 2015 09:53:53 -0400, Richard Hipp <d...@sqlite.org> wrote:
>Fossil has, for many years, detected potential forks prior to commit >and warned about them, or within the past few years has disallowed the >commit completely without the --allow-fork option. If two users are >committing concurrently, the fork detection fails, but even then the >second user gets a message "**** warning: a fork has occurred *****". >The problem arises when the second user does not notice, or chooses to >ignore, this message and the situational awareness within the >organization is such that nobody notices the fork plainly displayed on >the timeline. The check-in on the fork gets overlooked and fails to >make it into the next release. +1 >Proposed solutions include denying the ability to commit or push a >fork. But doesn't that just make the problem worse? We've already >established that users are in the habit of ignoring scary fork >warnings. Wouldn't they also just ignore the fact that the commit or >push failed? With a fork, at least the content is safely on the >server and can be easily recovered by anybody willing to take a moment >to review the timeline. But if the change never gets pushed, the >content is only on the developer's machine, out of view and >unrecoverable by anyone except the original developer. And if it >never gets committed, then the work might be lost even to the original >developer. How is that an improvement? +1 >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. +1 >The "fossil update|co|checkout BRANCH" command takes you to the most >recent check-in for BRANCH. If BRANCH contains leaves that are not >the most recent check-in, it seems like this would be a good time to >issue a warning. +1 > The command might even fail with the message that >BRANCH is ambiguous and then provide a list of all possible SHA1 >values that BRANCH could resolve to, enabling the user to retry the >command with an unambiguous SHA1 hash. +1 >Another approach would be to provide commands (such as "fossil forks") >that actually show problems in the tree, for people who are actually >interested - for example the release manager. A web-version of >"fossil forks" with graphical pictures of each fork would be nice to >have. +1 >One other thing: We ought to intentionally preserve several forks >within the Fossil self-hosting repository, so that we always have test >cases for the above mechanisms readily at hand. +1 SUM: +7 -- Thanks & Regards, Kees Nuyt _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
