On Wed, 2014-04-09 at 14:48 +0100, Graham Cobb wrote: > On 09/04/14 13:49, Patrick Ohly wrote: > > On Wed, 2014-04-09 at 12:45 +0100, Graham Cobb wrote: > >> Conflict resolution/merging is a very hard problem, with no perfect > >> solutions. It is really a separate issue which could do with much more > >> research and co-ordinated effort, as the heart of the sync problem. I > >> wonder if this could be separated out into a self-contained module so > >> that different implementations could be tried (or even supported -- see > >> below). > > > > I doubt that a separate module would work outside of one particular > > engine. It would be way too tightly integrated into data handling and > > sync APIs of the engine. > > I wasn't actually thinking about different engines -- I was more > thinking of allowing the SE engine to use different implementations of > conflict resolution (such as the interactive and non-intractive > mechanisms discussed later).
To some extend that is already possible. Merging two conflicting items can be done entirely using the builtin scripting language and a custom script. > >> In the short term, the most critical thing is to allow the user to see > >> what is happening, and to fix it if necessary. > > > > That's what the automatic backup, restore and DB diff (--print-changes) > > is for. But not all users can enable that for performance and/or storage > > reasons, or they won't know what to do with it. > > 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. > >> In the immediate case, I would suggest allowing some sort of dry-run > >> capability (frankly I have always been surprised this doesn't seem to > >> exist today) > > > > It's hard to do with the existing Synthesis engine (it expects the data > > stores to really apply changes) and protocols. SyncML has sync anchors > > and could in theory repeat the last sync, but I suspect that many > > implementations will not implement that correctly. libsynthesis does (as > > far as I know), but SyncEvolution doesn't. > > I agree that relying on anchors would not be good. But having a dry-run > capability would be really useful even if it only worked, for now, on > local syncs. Local sync with what? 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. > > You could disable printChanges. Then if you want, run synccompare > > manually on the data dumps. There's no SyncEvolution command line > > support for that, though, other than listing session dirs. > > 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. > Personally I dislike the synccompare approach -- I have seen it report > strange things (like reporting two halves of two different entries as a > changed entry, presumably because it is doing textual comparisons on a > single file containing all entries) and taking forever to run on large > databases. True, that approach has limitations. On the other hand it can detect bugs in the engine because it doesn't rely on the engine and looks at the raw data instead. That was the original motivation for writing it. -- 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. _______________________________________________ SyncEvolution mailing list [email protected] https://lists.syncevolution.org/mailman/listinfo/syncevolution
