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. -- ----- stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users