Thus said Martin Gagnon on Fri, 30 May 2014 05:55:58 -0400:
> Same for me, I always use autosync=1 together with the dont-push=1
> setting for that. Look like an option got added by someone that didn't
> know about the other.
The actually do serve different purposes. dont-push=1 prevents
Thus said Matt Welland on Thu, 29 May 2014 09:00:56 -0700:
> Retry on autosync would be a big help in my environment. Autosync
> failures due to overlapping access are a regular and annoying
> occurrence. I like Stephan's approach of 0, 1, N for off, on,
> multi-try
Have y
Thus said Ron Wilson on Fri, 30 May 2014 09:42:44 -0400:
> As I recall, the 2 options have slightly different affects.
> "pull-only" only affects auto sync, while "dont-push" affects both
> manual and auto sync. A manual push will, of course, still push.
``pull-only'' pertains onl
On Fri, May 30, 2014 at 5:55 AM, Martin Gagnon wrote:
> Le 29 mai 2014 16:10, "Stephan Beal" a écrit :
>
> >
> > Wasn't even aware of pull-only until earlier today.
>
> snip
>
> Same for me, I always use autosync=1 together with the dont-push=1 setting
> for that. Look like an option got adde
On Fri, May 30, 2014 at 11:55 AM, Martin Gagnon wrote:
> Same for me, I always use autosync=1 together with the dont-push=1 setting
> for that. Look like an option got added by someone that didn't know about
> the other.
>
LOL - wasn't aware of dont-push, either ;)
--
- stephan beal
http:/
Le 29 mai 2014 16:10, "Stephan Beal" a écrit :
>
> Wasn't even aware of pull-only until earlier today.
snip
Same for me, I always use autosync=1 together with the dont-push=1 setting
for that. Look like an option got added by someone that didn't know about
the other.
--
Martin G.
___
I was going to +1 sbeals idea, but the pull-only autosync note came up, and
now I think I may not know all there is about autosync. Thanks for keeping
it interesting, folks.
On May 29, 2014 8:34 PM, "Andy Bradford" wrote:
> Thus said Stephan Beal on Thu, 29 May 2014 22:10:24 +0200:
>
> > Wasn't e
Thus said Stephan Beal on Thu, 29 May 2014 22:10:24 +0200:
> Wasn't even aware of pull-only until earlier today. i am completely
> ambivalent on the topic - never had any problems with autosync - this
> was just what came to mind when you posted. Seemed easier than adding
> a new option, but
On Thu, May 29, 2014 at 11:38 AM, Andy Bradford
wrote:
> I agree that for network related failures, retry won't help. Others have
> reported non-network related failures (primarily due to locking or other
> similar problems).
Intermittent network failures can be a problem.So, when I'm not at th
Wasn't even aware of pull-only until earlier today. i am completely
ambivalent on the topic - never had any problems with autosync - this was
just what came to mind when you posted. Seemed easier than adding a new
option, but was not aware of the pull-only feature (so a second option
might be simpl
Thus said Stephan Beal on Thu, 29 May 2014 21:44:12 +0200:
> 0 means no autosync, 1 means one attempt (same as now), 2+ means retry
> N times. But because there really is no difference between "try" and
> "retry", 1+ is the same logic:
I assume we're talking about a different setting than
0 means no autosync, 1 means one attempt (same as now), 2+ means retry N
times. But because there really is no difference between "try" and
"retry", 1+ is the same logic:
For(i=0; i < N; ++i) attempt to sync, break on success.
(sent from a mobile device - please excuse brevity, typos, and top-p
Thus said Stephan Beal on Thu, 29 May 2014 18:06:49 +0200:
> That could also (more simply, i think) be interpreted as:
>
> 0 == off
> 1+ == number of times to try
I'm a bit confused, however, in how 0 and 1 should be interpreted...
Given that Fossil currently does 1 autosync attempt: Doe
On Thu, May 29, 2014 at 6:00 PM, Matt Welland wrote:
> Retry on autosync would be a big help in my environment. Autosync failures
> due to overlapping access are a regular and annoying occurrence. I like
> Stephan's approach of 0, 1, N for off, on, multi-try
>
That could also (more simply, i thi
Retry on autosync would be a big help in my environment. Autosync failures
due to overlapping access are a regular and annoying occurrence. I like
Stephan's approach of 0, 1, N for off, on, multi-try
On Thu, May 29, 2014 at 8:49 AM, Andy Bradford wrote:
> Thus said Marc Simpson on Thu, 29 May 20
Thus said Marc Simpson on Thu, 29 May 2014 16:35:50 +0100:
> I'd rather autosync remained a toggle (indicating whether work is
> local or not). A separate setting for number of retries seems
> reasonable.
Well, strictly speaking, autosync isn't a toggle, it can also be set to
``pul
Thus said Richard Hipp on Thu, 29 May 2014 10:53:57 -0400:
> In my experience, autosync only fails when WIFI is down (or turned
> off). Retries won't help that. It just takes longer to finish.
I agree that for network related failures, retry won't help. Others have
reported non-network relate
I'd rather autosync remained a toggle (indicating whether work is
local or not). A separate setting for number of retries seems
reasonable.
On Thu, May 29, 2014 at 3:56 PM, Stephan Beal wrote:
> On Thu, May 29, 2014 at 4:53 PM, Richard Hipp wrote:
>>
>> On Thu, May 29, 2014 at 10:46 AM, Andy Bra
On Thu, May 29, 2014 at 10:46 AM, Andy Bradford
wrote:
> Hello,
>
> I introduced some code on the autosync-tries branch that causes autosync
> to retry if it fails, up to a maximum of 3 tries.
>
> 1) Should autosync retry?
>
In my experience, autosync only fails when WIFI is down (or turned off)
On Thu, May 29, 2014 at 4:53 PM, Richard Hipp wrote:
> On Thu, May 29, 2014 at 10:46 AM, Andy Bradford
> wrote:
>
>> 1) Should autosync retry?
>>
>
> In my experience, autosync only fails when WIFI is down (or turned off).
> Retries won't help that. It just takes longer to finish.
>
Maybe inst
Hello,
I introduced some code on the autosync-tries branch that causes autosync
to retry if it fails, up to a maximum of 3 tries.
1) Should autosync retry?
2) Should the number of tries be configurable?
I would like to either merge or abandon, but would like some additional
feedback first. Here
21 matches
Mail list logo