On Sat, Apr 25, 2015 at 9:50 PM, Andy Bradford <amb-fos...@bradfords.org> wrote:
> Thus said Matt Welland on Sat, 25 Apr 2015 15:05:54 -0700: > > > 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. > > While the change is not yet in an official release (it's now merged to > trunk, but definitely in ``testing'' mode), would you mind trying the > latest to see how it works in your environment: > > http://www.fossil-scm.org/index.html/info/560483f50436c9f7 > Yes, we'll test this early next week. Thanks. > > > 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. > > Perhaps because we have not experienced the large number of forks that > you are encountering. The last time I checked, there were not yet 80 > forks in Fossil in it's entire not yet 8 years of existence. Not very > many to be sure. How many do you have in 1 day? 1 week? 1 month? > Several a week in one repository, close to one a day until we restructured the repo to reduce the incidence (among other reasons). Ironically that is less problematic (time consuming and annoying perhaps, but not troublesome) than some of the other repos where it might be a few a year. If they happen regularly then the developers get sensitized to the problem and are on the look out for it. Where it is rare, when one happens it can be a serious problem if no one catches it. > A fork is seen as a failure of fossil to handle a commit that requires > > tiresome manual intervention to fix. > > Perhaps because the person who committed the fork was not aware of it, > nor was anyone else? If someone had been alerted to the presence of the > fork, would it have been dealt with when it happened? > Yes, and this is precisely why I feel so strongly that fossil should be quite aggressive about warning users about forks. Most forks take under 30 seconds to fix. They really are a major problem only when they happen silently. In another post I provided a script that I believe replicates the scenario where forks are being silently created (inserted below). As I recall neither party gets notified when a fork happens due to this scenario. A simple script to simulate the colliding commits that caused silent forks: #!/bin/bash rm -rf testdir mkdir -p testdir/{a,b} fossil init testdir/test-fork.fossil function clone_open () { area=$1 (cd testdir/$area; fossil clone file://../test-fork.fossil test-fork.fossil; fossil open test-fork.fossil; fossil set autosync 0; fossil set web firefox) } function addfile () { area=$1 fname=$2 (cd testdir/$area;fossil add $fname) } function modfile () { area=$1 fname=$2 echo $RANDOM|md5sum|awk '{print $1}' > testdir/$area/$fname } function pull () { area=$1 (cd testdir/$area;fossil pull) } function commit () { area=$1 (cd testdir/$area;fossil commit -m "committed from area $a") } function push () { area=$1 (cd testdir/$area;fossil push) } # do it clone_open a clone_open b modfile a file1 addfile a file1 modfile b file2 addfile b file2 # commit from a starts pull a commit a # commit from b starts pull b commit b # commit from a completes push a # commit from b completes push b Thanks, > > Andy > -- > TAI64 timestamp: 40000000553c6ec8 > > > _______________________________________________ > 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
