On Sat, 18 Apr 2015 15:53:53 +0200, 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
yes.
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.
no. I believe the checkout should just proceed as it precently does in
this case. it seems clear that the intent of `fossil up BRANCH' is just
that, rather than going to any of the fork-related leaves.
Another approach would be to provide commands (such as "fossil forks")
that actually show problems in the tree, for people who are actually
that would be very good. as forks are sometimes simply spurious (there
were some never-quite-cleared-up reports in the past of forks suddenly
appearing even in single-developer projects -- I, too, experienced this at
least onece) or due to erroneous checkins. I would argue for restricting
the list by default to "unclosed" fork leaves so that the reported list of
forks is restricted to the forks still not dealt with (either are not just
closed or not yet merged back). maybe this list could additionally be
generated by `fossil branch' like
trunk
dev
experimental
--
unresolved forks:
{sha1} (parent branch: {parent branch} dated {date})
so that it can be noted by the user even if he is not explicitly hunting
for the forks.
interested - for example the release manager. A web-version of
"fossil forks" with graphical pictures of each fork would be nice to
have.
CLI seems rather more important to me, but yes, it would be nice.
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.
I believe somewhere in this thread it was argued that forks can be
intended/beneficial. I feel that such use should be "officially
discouraged" and to proceed from a consensus that (unclosed) fork-leaves
should be taken as indicator of a lurking problem in the project.
--
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
