On Sat, Apr 25, 2015 at 1:48 PM, Richard Hipp <d...@sqlite.org> wrote:
> On 4/25/15, Matt Welland <mattrwell...@gmail.com> wrote: > > There is no need for a forks page. All that is needed is to keep > developers > > informed ... > > To my ears, those two sentences directly contradict one another. > > The purpose of the web interface (at least the purpose for which it > was originally created) is to promote situational awareness. The idea > is that a developer (or project manager or BDFL) can quickly glance at > a few pages and gain a good understanding of what is going on with the > whole project, on all its various branches. Links are provided to dig > down into details as desired. The intent is to help all participates > maintain an accurate mental model of the project and avoid "tunnel > vision" wherein they only see their little piece and miss the big > picture. > That is a fine vision and indeed the fossil UI is much appreciated however for many folks having to take the focus off the command line and the work at hand to go explore the UI is an in-the-zone killer. Our preferred work style is to get feedback from the command line where possible. If notified of a fork during update, sync or commit a developer may resort to the UI to determine what happened but the fix is done at the command line. >From reading the posts it seems quite a few people on this list either perceive or experience forks differently that myself and others on my team. A fork is seen as a failure of fossil to handle a commit that requires tiresome manual intervention to fix. If I have to ask the team to poll the UI to see if there was a fork my credibility and enthusiasm for fossil will take another hit. This is the scenario as the developers experience it, happening just often enough in our very busy repositories to irritate people: Developer A makes a commit. Excellent, all done with the task at hand. Time passes. Developer B runs update and does some work with the expectation that Developer A's commit is there. Thinks don't work, confusion ensues, developer A is called in and asked "did you do the task?", he replies "yes, committed yesterday" they dig through the timeline and see the fork, merge it and we are back to normal. But precious time was WASTED. The expectation is that if a commit succeeds *it is a part of the series of commits on that branch*. This expectation is valid in git, it is valid in subversion, it is valid in DesignSync. It is not valid in Fossil. By all means add a forks page to fossil. Perhaps it will be useful to some but I merely responded to this thread to ensure that anyone putting effort into this was aware that adding that feature adds zero value to solving my problem. To be redundantly clear. If I have to poll the timeline or some /forks page to determine that I've borked up my repo (yes, a fork is that bad) then fossil is not a viable tool for a corporate environment where developers time is $$$$$$. There is NO valid reason for a fork to persist in a repo. Fixing a fork is TRIVIAL, merge it, close it or rename it to a new branch name. At issue here is that forks are often NOT apparent. Make them adequately apparent and in your face and this limitation of fossil is tolerable. > It seems to me that a page showing forks might well maintain > situational awareness. > > -- > 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
