Re: [SyncEvolution] keeping in sync _two_ phones
On Mo, 2010-11-08 at 09:43 +0000, Giancarlo wrote:
I'm trying to keep in sync two phones with my evolution, by using
syncevolution.
My phones are a Nokia E61 and a Nokia 6220 classic. Both are S60, but E61 is
older than 6220.
It happens to me quite often that after a sync I get data duplication, most
often on the E61. The only way I found to get rid of such duplication would be
to sync one-way from the server to the phone and then to re-sync immediately,
again one-way, from the phone to the server. In such a way, the next two-way
sync would work.
It is not clear to me why you need a "refresh-from-client" sync
immediately after the "refresh-from-server". Everything should be ready
for a normal two-way sync after "refresh-from-server". What happens if
you don't do the "refresh-from-client"?
But after such an adjustment, there will be very likely the same
problem with
the second phone, so to recover I will have to do the same with the second
phone. And this will lead to problems with the first, and so on.
The problem with "refresh-from-client" is that it wipes out all data on
the server. The next sync with your other phone therefore has to delete
all contacts on that phone, which will lead to conflicts if that data
was modified there in the meantime.
In brief, the only way to keep all in order is to sync two-way one
phone and
one-way the other. Therefore I can never change my PIM data from the phone which
I sync one way: such changes wuould be lost at the first sync.
I'm not sure whether this is a regression: I do remember that everything looked
fine before the last two versions of syncevolution, even though I had other
problems (which are described in the wiki).
Anyone has ever tested syncing with two different phones?
I haven't tested it much, but it should work as far as SyncEvolution is
concerned.
--
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.