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

Reply via email to