On 09/04/14 15:51, Patrick Ohly wrote: > To some extend that is already possible. Merging two conflicting items > can be done entirely using the builtin scripting language and a custom > script.
Ah. Something else to look into one day. >> Performance and storage are important but I don't think they are what >> limits this today. I think it is usability. Particularly in terms of >> undoing individual changes (even of individual fields within a single >> object). > > I remember that Ove turned off "dumpData" for Maemo because it was slow. > But perhaps my memory fails me here. I certainly turn it off in my Jolla syncs, for exactly the reason Ove mentions in his reply. But I think that is more to do with the need to dump the whole database than with the concept of recording changes. Particularly if we could find a way to record the changes out of the sync itself, rather than by doing comparisons after the sync is complete. > The involved backends would need to support reporting changes starting > from some particular state multiple times. It's doable for EDS and > WebDAV (but not currently implemented), whereas ActiveSync would rely on > the server to support old anchors which (as far as I remember) not all > servers do. Good point. I still want to think about a way to do dry runs but I understand the issue here. Maybe we don't need dry runs if we can make user correction of incorrect conflict resolutions usable. >> Yes, but I was thinking of better ways to do the print-changes job, by >> driving it from the conflict resolution engine itself. > > Patches welcome, as they say. I personally don't have an idea how this > could be implemented in a user-friendly way. The internal representation > is fairly abstract; definitely not what the user wants to see. This seems a more solvable problem than the dry-runs problem, without completely rewriting the engine or requiring any impact on the sync protocols themselves. But, as you say, it requires someone to look into the code and come up with a solution. Maybe I will get to it one day :-( _______________________________________________ SyncEvolution mailing list [email protected] https://lists.syncevolution.org/mailman/listinfo/syncevolution
