For what it's worth, I agree with this. Loading the protocol and/or "in-band" processing sounds like a horrible error to me. I'd suggest some "offline" local processing, if anything. Something like:
$ fossil show-forks That (if this doesn't exist already) will report potential forks that one can investigate and resolve by the existing abilities we already have. I think fossil has done a reasonable(ish) job staying simple, and I think that will be the key to it's continued success. On Apr 18, 2015 6:53 AM, "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. > > 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 >
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
