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 tabl
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
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 p
On Mon, Jun 23, 2014 at 12:29 AM, Joe Mistachkin wrote:
>
> Joe Prostko wrote:
>>
>> If I move the zlib.h inclusion below the crypto.h inclusion's #endif,
>> then Fossil compiles and works fine with both GCC2 and GCC4.
>>
>
> Fixed on trunk. Thanks for the report.
Cool, thanks for the fix! If t
4 matches
Mail list logo
