Thus said Donny Ward on Sat, 21 Jun 2014 17:29:07 -0700:
I have two versions of my repository that I've saved from a while ago,
the last time I ran into this syncing issue. I've linked them both
here, hoping that someone can analyze them and figure out what the
issue is.
Ok, the
Thus said Andy Bradford on 24 Jun 2014 00:21:23 -0600:
If I understand this correctly, it will delete from the unclustered
table but leave behind any newly added cluster artifacts that were
just created. But what about phantoms that might exist in the
unclustered table at that
Thus said Andy Bradford on 24 Jun 2014 00:39:20 -0600:
Perhaps the cluster rotation mechanism is rotating out clusters faster
than clients are able to consume them in this scenario? So clients
that update infrequently will miss some clusters which will exist in
the unclustered table for
Thus said Donny Ward on Sat, 21 Jun 2014 17:29:07 -0700:
I have two versions of my repository that I've saved from a while ago,
the last time I ran into this syncing issue. I've linked them both
here, hoping that someone can analyze them and figure out what the
issue is.
Indeed it
On 22 June 2014 08:37, Andy Bradford amb-fos...@bradfords.org wrote:
Thus said Donny Ward on Sat, 21 Jun 2014 17:29:07 -0700:
...
Then look at the http-* files that appear:
$ grep gimme http-request-* | random 100
http-request-2.txt:gimme 3621fa11299ea8ab263e754cec37690d4581f660
Thus said Michai Ramakers on Sun, 22 Jun 2014 10:44:05 +0200:
It looks like at least this random selection are all files that were
part of checkin a9b1344817, perhaps all of them are.
Thanks both for putting in time pinpointing this. This is probably no
news: diffing the complete
I have two versions of my repository that I've saved from a while ago, the
last time I ran into this syncing issue. I've linked them both here, hoping
that someone can analyze them and figure out what the issue is. In this
case, the artifact not being synced is a new branch commit (see commit
Sorry for the vague message, but I don't have a specific test case.
Twice this week, I encountered a situation where I did a commit from one
machine, and an update from the second -- and the second did not get the
latest updates.
The first time was about a week ago; the second time was a few
On Thu, Jun 12, 2014 at 10:40 AM, Ron Aaron r...@ronware.org wrote:
Sorry for the vague message, but I don't have a specific test case.
Twice this week, I encountered a situation where I did a commit from one
machine, and an update from the second -- and the second did not get the
latest
Great! Thanks for the tip, and hope the bug is found...
Best regards,
Ron
On 06/12/2014 05:43 PM, Richard Hipp wrote:
On Thu, Jun 12, 2014 at 10:40 AM, Ron Aaron r...@ronware.org
mailto:r...@ronware.org wrote:
Sorry for the vague message, but I don't have a specific test case.
Thus said Ron Aaron on Thu, 12 Jun 2014 17:40:02 +0300:
Twice this week, I encountered a situation where I did a commit from
one machine, and an update from the second -- and the second did not
get the latest updates.
What sync method was used on the first machine? On the second
On Thu, Jun 12, 2014 at 6:00 PM, Andy Bradford amb-fos...@bradfords.org
wrote:
This has been mentioned before a few times, but so far, nobody has been
able to provide enough details to reproduce it and none of the Fossil
devs have seen it.
It's come up 3 or 4 times the past year, IIRC. i
On 12 June 2014 19:54, Stephan Beal sgb...@googlemail.com wrote:
On Thu, Jun 12, 2014 at 6:00 PM, Andy Bradford amb-fos...@bradfords.org
wrote:
This has been mentioned before a few times, but so far, nobody has been
able to provide enough details to reproduce it and none of the Fossil
I believe I have seen this issue. It's been a while, but here is the
scenario as far as I can recollect:
1. Assume there are three repo copies in a master/client topology: M,
C1, and C2. M is the master, and C1/C2 are clones of the master (meaning
that C1 and C2 don't know about each
It may be that you need to replace the one giant file in the below
scenario with a great many files that as a whole take up a lot of bytes.
I don't remember. Sorry. :-/
On Thu, Jun 12, 2014 at 2:46 PM, Eric Rubin-Smith eas@gmail.com wrote:
I believe I have seen this issue. It's been a
On Thu, Jun 12, 2014 at 02:46:09PM -0400, Eric Rubin-Smith wrote:
I believe I have seen this issue. It's been a while, but here is the scenario
as far as I can recollect:
1. Assume there are three repo copies in a master/client topology: M, C1,
and C2. M is the master, and C1/C2 are
On 06/12/2014 11:31 PM, Martin Gagnon wrote:
On Thu, Jun 12, 2014 at 02:46:09PM -0400, Eric Rubin-Smith wrote:
I believe I have seen this issue. It's been a while, but here is the
scenario
as far as I can recollect:
1. Assume there are three repo copies in a master/client topology: M,
Thus said Ron Aaron on Fri, 13 Jun 2014 07:43:25 +0300:
So I could have the situation where C1 pushes and is also pulling
(though locks should prevent any problems), and later on C2 pulls. I
don't have the super-long-time push, but it does seem to occur more
often when the push
Thus said Eric Rubin-Smith on Thu, 12 Jun 2014 14:46:09 -0400:
I have no idea how the sync code works, but at the time I suspected
that there is some sort of optimization involving timestamps, and a
slow sync can cause that code to get confused and miss some artifacts.
May or may not
Hi Andy -
On 06/13/2014 08:15 AM, Andy Bradford wrote:
I can continue to try this route to see if there might be something.
By the way, what version of Fossil are you running on your clients (and
server)?
As I said, I'm not sure what the problem is, but it seems to have
happened more often
In the case yesterday they were edits. In a previous one it was a large
amount of deletes, in a more distant one it was an addition of two large
files.
Essentially, I do a fossil upd and the timeline does not show the new
checkin at all. If I look at the main repo, I see the checkin just
fine,
21 matches
Mail list logo
