Is there a known problem with time skew in the first place? Maybe
resolving that would fix these untraceable phantoms.
I also bumped into something similar when hosting the same .fossil on
two different servers with a time skew between them. Everything was
fine when I fixed the time settings,
On Fri, Apr 25, 2014 at 8:45 AM, Ory Drilon o...@drilon.com wrote:
Is there a known problem with time skew in the first place? Maybe
resolving that would fix these untraceable phantoms.
Not that i'm aware of - i was speculating that maybe the clock was used as
an optimization for the client
On Fri, Apr 25, 2014 at 8:32 AM, Stephan Beal sgb...@googlemail.com wrote:
On Fri, Apr 25, 2014 at 8:45 AM, Ory Drilon o...@drilon.com wrote:
Is there a known problem with time skew in the first place? Maybe
resolving that would fix these untraceable phantoms.
Not that i'm aware of - i was
just for the record, I believe I encountered something similar:
I have a very simple setup: a remote (cgi-served) repo (acting
essentially only as a backup but publicly accessible) and _one_ local
clone where only _one_ user (me) does checkins (the owner of the remote
server _could_
On Thu, Apr 24, 2014 at 10:36 AM, j. van den hoff veedeeh...@googlemail.com
wrote:
maybe this additional observation helps to get this missing commit
phenomenon sorted out -- it really is a bit scary even if nothing really
bad is happening to the repo content.
It is indeed, but until we can
Thus said Matt Welland on Tue, 22 Apr 2014 22:22:16 -0700:
This has happened enough that I'm sure it was a real issue but it has
been long enough since anyone reported it to me that I'd assumed it
was fixed.
Unfortunately, nobody has been able to reproduce so it's kind of hard to
fix. The
Out of curiosity: is there a proxy between them? A caching proxy
server might explain this behaviour (in which case i think there's
a workaround).
No proxy involved. The three machines are sitting on my desk. As a side
note, the server is a raspberry PI and it does a great job at hosting
On Wed, Apr 23, 2014 at 9:18 AM, Samuel Debionne
samuel.debio...@ujf-grenoble.fr wrote:
The only clue for you I have is that a rebuild on the server did the
trick. I'm no sure what fossil rebuild does though...
Rebuild basically reconstructs the db from its underlying metadata. A very
brief
On Wed, Apr 23, 2014 at 9:18 AM, Samuel Debionne
samuel.debio...@ujf-grenoble.fr wrote:
No proxy involved. The three machines are sitting on my desk. As a side
note, the server is a raspberry PI and it does a great job at hosting
fossil repo !
...
The three machines are clock sync with NTP.
On Wed, Apr 23, 2014 at 8:38 AM, Stephan Beal sgb...@googlemail.com wrote:
On Wed, Apr 23, 2014 at 9:18 AM, Samuel Debionne
samuel.debio...@ujf-grenoble.fr wrote:
The only clue for you I have is that a rebuild on the server did the
trick. I'm no sure what fossil rebuild does though...
On Wed, Apr 23, 2014 at 6:12 PM, Andreas Kupries
andre...@activestate.comwrote:
I am wondering if the rebuild will also redo the cluster artifacts.
i have no idea - i'm not at all familiar with the sync-related code
(because it's way down on the list of libfossil's TODOs ;).
If these are
On Wed, Apr 23, 2014 at 9:15 AM, Stephan Beal sgb...@googlemail.com wrote:
On Wed, Apr 23, 2014 at 6:12 PM, Andreas Kupries andre...@activestate.com
wrote:
I am wondering if the rebuild will also redo the cluster artifacts.
i have no idea - i'm not at all familiar with the sync-related code
On 23 April 2014 18:28, Andreas Kupries andre...@activestate.com wrote:
Another would be to see what the --verily is doing differently from
regular sync.
For ex. does it bypass the cluster optimizations ?
I.e. any code bypassed by --verily would be suspect
I have no clue on sync logic at
On Wed, Apr 23, 2014 at 09:12:28AM -0700, Andreas Kupries wrote:
I am wondering if the rebuild will also redo the cluster artifacts.
No, but it does rebuild the phantom table, a.k.a. the missing artifacts.
Joerg
___
fossil-users mailing list
Thus said Michai Ramakers on Wed, 23 Apr 2014 18:34:32 +0200:
I have no clue on sync logic at all, but perhaps this helps: in all
cases I remember here (3 or so), when sync of commit on host A was not
seen during sync on host B, doing a dummy-commit on host A, then
pulling again on
Hello all,
Here is a sequence I'm doing several times a day for years and that did
not work this morning :
fossil commit -m Blabla from my PC
fossil update from my Mac
But this time the update did not get the latest checkin.
A complete clone / open in a different directory
Hello,
not sure if this is the same issue you're seeing, but this has come up
here a few times - commits not seen on pull/sync from different host.
There's a '--verily' option to 'sync' iirc, to work around what may be
a bug; see for example this mail thread:
Thus said Samuel Debionne on Tue, 22 Apr 2014 11:36:46 +0200:
Here is a sequence I'm doing several times a day for years and that did
not work this morning :
fossil commit -m Blabla from my PC
fossil update from my Mac
Has a fork happened? Have a look at the timeline
There's a '--verily' option to 'sync' iirc, to work around what may be
a bug; see for example this mail thread:
https://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg12979.html.
I'm not sure the issue has been solved in the meanwhile. (I haven't
seen missing commits since that
On Tue, Apr 22, 2014 at 11:51 AM, Michai Ramakers m.ramak...@gmail.comwrote:
not sure if this is the same issue you're seeing, but this has come up
here a few times - commits not seen on pull/sync from different host.
There's a '--verily' option to 'sync' iirc, to work around what may be
a
On Tue, Apr 22, 2014 at 11:36 AM, Samuel Debionne
samuel.debio...@ujf-grenoble.fr wrote:
fossil commit -m Blabla from my PC
fossil update from my Mac
But this time the update did not get the latest checkin.
Out of curiosity: is there a proxy between them? A caching
On Tue, Apr 22, 2014 at 9:36 AM, Stephan Beal sgb...@googlemail.com wrote:
On Tue, Apr 22, 2014 at 11:36 AM, Samuel Debionne
samuel.debio...@ujf-grenoble.fr wrote:
fossil commit -m Blabla from my PC
fossil update from my Mac
But this time the update did not get the
On Tue, Apr 22, 2014 at 9:47 PM, Matt Welland estifo...@gmail.com wrote:
I have seen this issue a few times and this was with using file:// for the
transport to the server. I've fixed it by doing a checkout to another
branch and back. If I recall correctly a checkout to the current branch was
On Tue, Apr 22, 2014 at 1:03 PM, Stephan Beal sgb...@googlemail.com wrote:
On Tue, Apr 22, 2014 at 9:47 PM, Matt Welland estifo...@gmail.com wrote:
I have seen this issue a few times and this was with using file:// for
the transport to the server. I've fixed it by doing a checkout to another
Thus said Stephan Beal on Tue, 22 Apr 2014 18:07:08 +0200:
Just to confirm that: this has come up several times before in the
past year and, so far, has remained unexplained. We're not sure what
causes it or how to reproduce it. (At least i don't remember seeing
any commits/posts
On Tue, Apr 22, 2014 at 9:30 PM, Andy Bradford amb-fos...@bradfords.orgwrote:
Thus said Stephan Beal on Tue, 22 Apr 2014 18:07:08 +0200:
Just to confirm that: this has come up several times before in the
past year and, so far, has remained unexplained. We're not sure what
causes it
26 matches
Mail list logo
