On Fr, 2010-12-17 at 14:08 +, Lukas Zeller wrote:
> On Dec 17, 2010, at 8:47 , Patrick Ohly wrote:
> >> Now it turns out that there's a bad bug here, which probably explains
> >> all this (and maybe other) weird behaviour.
> >
> > I'm glad that you got to the bottom of this. Much better than p
On Do, 2010-12-16 at 17:35 +, Lukas Zeller wrote:
> Hello Patrick,
>
> On Dec 9, 2010, at 17:47 , Patrick Ohly wrote:
>
> > I might have found it.
> >
> > Scenario:
> > - SERVER is the ID on the server, CLIENT on the client
> > - server has a mapping from SERVER to #35 (ident 2) and to CLIEN
Hello Patrick,
On Dec 9, 2010, at 17:47 , Patrick Ohly wrote:
> I might have found it.
>
> Scenario:
> - SERVER is the ID on the server, CLIENT on the client
> - server has a mapping from SERVER to #35 (ident 2) and to CLIENT (ident 1)
Where is this from? I assume it is from a previous session
Hello!
Another user confirmed that corrupted map data was affecting him, even
after wiping out all data and running "refresh-from" kind of syncs.
Currently I have to tell SyncEvolution users to recover by removing the
file in which the map is stored (BMC #10358).
I would like to change SyncEvolut
On Fr, 2010-12-10 at 11:31 +0100, Patrick Ohly wrote:
> On Do, 2010-12-09 at 16:47 +, Patrick Ohly wrote:
> > The fTempGUIDMap is a map tempLocalID->ID. It now contains #65->SERVER
> > and #35->SERVER.
> >
> > But the map in the DB AP is a map from (ID, ident) -> ([remote ID],
> > flags).
> >
Hello Patrick,
On Dec 8, 2010, at 12:26 , Patrick Ohly wrote:
> On Mi, 2010-12-08 at 12:22 +0100, Patrick Ohly wrote:
>> I'm currently (involuntarily ;-) stress-testing this code by running
>> SyncEvolution<->SyncEvolution syncs with lots of iCalendar 2.0 items,
>> which happen to have very long
On Do, 2010-12-09 at 16:47 +, Patrick Ohly wrote:
> The fTempGUIDMap is a map tempLocalID->ID. It now contains #65->SERVER
> and #35->SERVER.
>
> But the map in the DB AP is a map from (ID, ident) -> ([remote ID],
> flags).
> It cannot hold both #65->SERVER and #35->SERVER.
[...]
> So, what i
On Do, 2010-12-09 at 13:18 +, Lukas Zeller wrote:
> > So you are saying that entries with ident == 2 are never meant to be
> > removed from the mapping?
>
> Not exactly that - what I'm saying is that these are (or should)
> always be removed all together. So either the list is still growing,
>
Hello Patrick,
On Dec 9, 2010, at 13:24 , Patrick Ohly wrote:
> On Do, 2010-12-09 at 11:26 +, Lukas Zeller wrote:
>> Still, the thing is that there's never a deletion of a single tempGUID
>> map entry (of course, there ARE deletions of map entries with other
>> types, but not of mapentry_temp
Hello Patrick,
On Dec 8, 2010, at 12:22 , Patrick Ohly wrote:
> The Synthesis engine has the feature that its backends are allowed to
> use IDs of arbitrary length. The engine will translate into IDs shorter
> than the maximum ID size supported by the peer.
It only works for the server, which ma
On Do, 2010-12-09 at 11:26 +, Lukas Zeller wrote:
> Still, the thing is that there's never a deletion of a single tempGUID
> map entry (of course, there ARE deletions of map entries with other
> types, but not of mapentry_tempidmap).
Does that type map to sysync::cMapID::ident?
In my mapping
Hello!
The Synthesis engine has the feature that its backends are allowed to
use IDs of arbitrary length. The engine will translate into IDs shorter
than the maximum ID size supported by the peer.
TLocalEngineDS::adjustLocalIDforSize() creates these temporary IDs,
using:
fTempGUIDMap.size() + 1
On Mi, 2010-12-08 at 12:22 +0100, Patrick Ohly wrote:
> I'm currently (involuntarily ;-) stress-testing this code by running
> SyncEvolution<->SyncEvolution syncs with lots of iCalendar 2.0 items,
> which happen to have very long IDs.
Related to this: is there some way to increase the maximum ID s
13 matches
Mail list logo
