Ah, yes; I forgot about autosync (I'm new to actually using fossil), but I don't think it's a flaw (see below).
On 3 October 2014 01:21, Stephan Beal <sgb...@googlemail.com> wrote: > On Thu, Oct 2, 2014 at 3:35 PM, David Mason <dma...@ryerson.ca> wrote: >> fossil update -q && fossil update 2>&1 | mail -s 'Fossil update' >> m...@he.re > > i've been mulling over this, and there's one fundamental flaw here: if > auto-sync is on (which it is by default), then fossil does not know if > there's work to be done until after it has done the network sync. In the > above operation, it would sync twice, _potentially_ with different results > for each (classical race condition). Having the hypothetical -q option > disable/bypass autosync doesn't seem like a solution because then its > result could very well differ from that of the second update (which > would sync, if enabled). > > When autosync is off, that wouldn't be a problem, but it is on by default > and is highly recommended to avoid unintended forks (the reason it's > turned on by default, IIRC, was unintended forks in fossil itself early on > in Fossil's history). > > Suggestions for an alternative approach, or concrete semantics, are > welcomed. If autosync is on and remote-url is on, then update -q should do the sync, and then check if there is work to do. Of course, if there are changes, but not on the branch the update refers to, then it returns false (this allows for e.g. an "in-production" branch). 4 points: 1) in my use case, this is the "master" repository, so has remote-url off so this isn't an issue. 2) this update will run every ?5? minutes,so if the update -q misses a change that the second update would get, it's no biggy... 5 minutes later will do fine (my alternative solution of checking timestamps wouldn't do any better) 3) if the second update finds more to do because of the second auto-sync, so much the better... and if not, the second autosync is a bit of extra network traffic, but again, no biggy 4) autosync on update actually obviates the need for the -q switch on sync (and as I think it through, sync doesn't need it anyway as either it found nothing to do in which case the update would have found nothing to do, or it changed things in which case the update would see the change (or not if the changes were to another branch)) Hope that is clear. Thanks ../Dave _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
