Hi Patrick, On 22.05.2012 09:18, Patrick Ohly wrote: > On Tue, 2012-05-22 at 00:53 +0200, Tom Kazimiers wrote: >> On Sun, May 20, 2012 at 09:03:30PM +0200, Patrick Ohly wrote: >>> On Sat, 2012-05-19 at 20:44 +0200, Tom Kazimiers wrote: >>>> Now it seems I can update my local VCard data with the help of these >>>> two commands: >>>> >>>> syncevolution funambol@default >>>> syncevolution local@default >>>> >>>> With this I am able to update the VCard folder (here: >>>> /home/tom/tmp/sync/vcard-dir). But I don't seem to be able to get changes >>>> from the VCard files back to the SyncML server. All the changes I make to >>>> the VCard files are not recognized by syncevolution (I try to sync with >>>> the last two commands as well). >>> >>> What changes do you make to the vCard files? It should be possible to >>> modify them (which must touch the last modified time stamp), add new >>> files (file name doesn't matter) and delete some. >> >> It now works using the approach you suggested. I might had something >> configured wrongly with my previous setup. However, it seems >> syncevolution has a problem with different entries having the same >> content. What happens is: a first synchronisation works without >> problems and also --status calls show no changes. But after I change a >> file and sync it I get new output from --status and sync calls: >> >> Data modified locally during synchronization: >> *** addressbook *** >> before sync | after >> sync >> removed during sync < >> >> > added during sync >> >> ------------------------------------------------------------------------------- >> >> > … >> >> > … >> … >> >> ------------------------------------------------------------------------------- >> >> Every duplicate entry is listed there as locally modified during sync. > > Modified or duplicated? What you show are added entries.
Sorry for not making me clear. A new initial sync shows no problems, the local (file) database has (of course) no changes. Then I modify an entry (one vCard file, say file "4") and sync it. The sync works fine, but starting with that sync (even in the sync's own output, it looks like if there is a --status call right after the syncing) I get the output above. Every duplicate in the data base gets marked as "added during sync". So if there are two identical vCard files (say "7" and "13"), one of them (e.g. "7") will show up as "added during sync". These are not necessarily the entries that one has been editing before. The duplicates have been there before and I don't think they are produced by syncevolution, gotta check this tonight. This needs some more investigation on my side. >> I >> did not change anything on those files, though. After having removed all >> duplicates, it works without problems. I just was wondering about this >> behaviour. > > It certainly doesn't look normal. Was this a normal two-way sync or a > slow sync? During a slow sync it can happen that the SyncML server > duplicates items. > > If it was a normal sync, then please send the syncevolution-log.html > file of that session. You can find it in the directory listed by > "syncevolution --print-sessions". It was a normal two-way sync. When I found out that the duplicates might be a problem (and I don't want duplicates anyway), I deleted them. To avoid searching for the correct log file and to see if the can be reproduced I just started from scratch: removed all vCards, refreshed from the server, copied a vCard file, named it differently and started the sync. The same problem as described above occurred. I sent the log file to you directly. Now every sync call shows the output until I remove the duplicate. >>> It will be easier to test this when syncing Funambol directly against >>> your @local file source: >>> syncevolution --configure \ >>> --template funambol \ >>> funambol@local \ >>> addressbook >>> >>> Strictly speaking, the "--template" parameter is redundant because >>> SyncEvolution would guess the right template based on the config name. >>> >>> Now you can synchronize with "syncevolution funambol@local" and check >>> for changes with "syncevolution --status funambol@local". The latter >>> command will tell you which changes in the file address book >>> SyncEvolution sees, without changing anything. >> >> Thanks a lot! This makes the configuration much easier. So this >> configuration adds a new peer (funambol) to the context "@local", >> doesn't it? And because the @local context has a file backend the peer's >> data gets stored in vCards? > > Correct. All peers in the same context share the same database settings. Alright, thanks. It's getting clearer :-). >> Next I will look into getting this to work with abook. > > It's quite likely that at some point you will find that abook and the > current file backend use different vCard flavors (= slightly different > properties). > > The format of the file backend is a mixture of all known properties, > defined in /usr/share/syncevolution/xml/datatypes/01vcard-profile.xml. > The downside for your purpose is that the engine doesn't know about > limitations in abook and/or won't format properties exactly as needed by > abook. Not sure how much of an issue that will be. Yes, I already noticed that. The vCard files of syncevolution are more detailed. I did't check if this is a problem for abook, though -- will do so in the next days. > As a first step you could modify that file directly, ignoring anything > with "rule=KDE". A cleaner solution would be needed to include your > changes back into SyncEvolution, for example by adding more conditional > sections and making the file backend format more configurable. Thanks for the hints. I will look into this if there are problems. > Or implement a backend which reads/writes abook directly... can you > program in C++? I am able to program C++, yes. Implementing an abook backend would IMHO be the cleanest solution. So if there are problems with abook reading syncevolution's more detailed vCard files, I will have look at the source code and see if I can add an abook backend. Maybe, I'll do this even if abook has no problems with those files. So checking out the developer documentation is one of the next steps. Cheers, Tom
signature.asc
Description: OpenPGP digital signature
_______________________________________________ SyncEvolution mailing list SyncEvolution@syncevolution.org http://lists.syncevolution.org/listinfo/syncevolution
