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

Reply via email to