Re: [SyncEvolution] Calendar Error in V 0.9 ("could not read revision identifier...")
On Tue, 2009-11-03 at 10:14 +0000, dev(a)welzl.info wrote:
[compiling 0.9.x from source difficult]
I don't remember what exactly was wrong, it's more than a
month ago; I just know that
simply going the confige/make/make install route as in V0.7/V0.8 didn't work. It took
some googling and trial and error especially during the configure stage to reach
"make install" finally.
I know this isn't helpful.
I'd like to continue playing with it in scratchbox, anyway, where everything was
even worse, so I might be able to recall some of the dirty details once I'm there
again... If your still interested. ;)
Yes, definitely.
> > [ERROR] calendar: could not read revision identifier for
item
> > pas-id-419B999600000002-birthday-rid: only refresh-from-client
> synchronization
> > is supported
>
> Hmm, we might have a code path in 0.9 which triggers this exception. I
> don't remember how it worked in 0.8, but this code probably has changed.
> I'll check.
Thanks. Syncevolution has become a part of my life and I'd hate to miss some of its
functionality.
I tried to reproduce the problem, but for me, refresh-from-client syncs
between the Birthday calendar and ScheduleWorld works fine. I tried with
SyncEvolution 0.9.1 (tagged, but not announced yet) compiled from source
and 0.9.1 beta 2.
Are you 100% sure that the sync is run in "refresh-from-client" mode?
The relevant INFO line in my case is:
[INFO] calendar: starting first time sync from client
and later:
+---------------+-------+-------+-------+-------+-------+-------+-----+
| birthday | 0/0 | 0/0 | 0/0 | 0/17 | 0/0 | 0/0 | 0 |
| refresh-from-client, 6 KB sent by client, 0 KB received |
| item(s) in database backup: 17 before sync, 17 after it |
+---------------+-------+-------+-------+-------+-------+-------+-----+
I've created an issue for this, but feel free to respond here.
http://bugzilla.moblin.org/show_bug.cgi?id=7759
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.