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.
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? 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. 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. 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. 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. 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. -- D. Richard Hipp d...@sqlite.org _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
