5 ms·

Differential Synchronization (2009)

14 points by panic 11y ago

amelius 11y ago
There is a fundamental problem with difference-based synchronization: the meaning (intention) of operations is not preserved. So while this method may work well in many cases in practice, there are classes of problems where the approach does not work. These problems may involve, for example, more complicated invariants that must hold between different parts of the data.
- kazinator 11y ago
  > complicated invariants that must hold between different parts of the data. Like, oh, when that data is, say, program code. Or text that has to be very consistent in the promises that it is making, or the requirements that it is specifying, and so of forth. I.e. this is good enough for sloppily written collaborative fiction. Writer W0 kills a character C0 in chapter 3, while writer W1 not knowing about this removal of C0 causes the character to appear in chapter 4. Oh well, the sky isn't going to fall! Even if these changes are in the same file, and even if the diff and patch identify textual conflicts, the chapters are too far apart for these changes to be so identified. The aim in this algorithm seems to be to make it so easy and transparent that all textual conflicts disappear, presumably because the target audience is users whose heads would explode at the idea of resolving a conflict. (Rather than just swell up and get sore, as in the case of software developers accustomed to version control.)
  - skybrian 11y ago
    Yes, this technique isn't intended for general-purpose synchronization. In particular it's not for offline synchronization. It's about something like Google Docs where everyone is online and lots of small diffs happen quickly. If there's a conflict, you can see it happening in real time and can easily correct it.
    - kazinator 11y ago
      Sure, if the whole document fits on a napkin, maybe. Could you always spot a conflict in real time if 15 people are plugging away at a 500 page document? It is quite hard for just one person to produce a big document, and hunt down all the inconsistencies.
      - skybrian 11y ago
        Yes, writing a book requires serious organizational skills. But no diff or sync algorithm is going to handle this so I don't know why you're bringing it up. When it matters (and for many docs it doesn't), it's up to the users to coordinate on their work. Even with programming, we don't use source control systems to find conflicts between distant parts of a program. We see if it compiles and all tests pass.
        kazinator 11y ago
        But no diff or sync algorithm is going to handle this so I don't know why you're bringing it up. Because that's what programmers do when they see claims like "robust and self-healing".
- toomim 11y ago
  I challenge you to provide an example of this vague claim of a problem. Why not record a video of yourself breaking the prototype?
  - kazinator 11y ago
    Gee, how can automatic merge without conflict identification break? In all the ways that automatic merge with conflicts, with even more opportunities. It's trivial for two editors to make edits to a sentence which are grammatical in isolation, but the system will merge them such that there is a problem. Original sentence: "There were two people present: Bob and Alice". Parallel edit 1: "There were three people present: Bob, Alice and Eve." Parallel edit 2: "There were three people present: Carlos, Bob and Alice." Seamlessly integrated, "self-healed", "robust" result: "There were three people present: Carlos, Bob, Alice and Eve".
    - skybrian 11y ago
      This is just moving the goalposts. Google Docs doesn't prevent this and nobody considers it a bug. Heck, a single-user textarea box doesn't prevent you from making this sort of logic error yourself (I do it all the time) and nobody considers it a bug. "Robust" and "self-healing" in this case are with respect to network faults and browser bugs that cause bizarre behavior that can confuse users.

14 points by panic 11y ago

There is a fundamental problem with difference-based synchronization: the meaning (intention) of operations is not preserved. So while this method may work well in many cases in practice, there are classes of problems where the approach does not work. These problems may involve, for example, more complicated invariants that must hold between different parts of the data.

kazinator 11y ago
> complicated invariants that must hold between different parts of the data. Like, oh, when that data is, say, program code. Or text that has to be very consistent in the promises that it is making, or the requirements that it is specifying, and so of forth. I.e. this is good enough for sloppily written collaborative fiction. Writer W0 kills a character C0 in chapter 3, while writer W1 not knowing about this removal of C0 causes the character to appear in chapter 4. Oh well, the sky isn't going to fall! Even if these changes are in the same file, and even if the diff and patch identify textual conflicts, the chapters are too far apart for these changes to be so identified. The aim in this algorithm seems to be to make it so easy and transparent that all textual conflicts disappear, presumably because the target audience is users whose heads would explode at the idea of resolving a conflict. (Rather than just swell up and get sore, as in the case of software developers accustomed to version control.)
- skybrian 11y ago
  Yes, this technique isn't intended for general-purpose synchronization. In particular it's not for offline synchronization. It's about something like Google Docs where everyone is online and lots of small diffs happen quickly. If there's a conflict, you can see it happening in real time and can easily correct it.
  - kazinator 11y ago
    Sure, if the whole document fits on a napkin, maybe. Could you always spot a conflict in real time if 15 people are plugging away at a 500 page document? It is quite hard for just one person to produce a big document, and hunt down all the inconsistencies.
    - skybrian 11y ago
      Yes, writing a book requires serious organizational skills. But no diff or sync algorithm is going to handle this so I don't know why you're bringing it up. When it matters (and for many docs it doesn't), it's up to the users to coordinate on their work. Even with programming, we don't use source control systems to find conflicts between distant parts of a program. We see if it compiles and all tests pass.
      - kazinator 11y ago
        But no diff or sync algorithm is going to handle this so I don't know why you're bringing it up. Because that's what programmers do when they see claims like "robust and self-healing".
toomim 11y ago
I challenge you to provide an example of this vague claim of a problem. Why not record a video of yourself breaking the prototype?
- kazinator 11y ago
  Gee, how can automatic merge without conflict identification break? In all the ways that automatic merge with conflicts, with even more opportunities. It's trivial for two editors to make edits to a sentence which are grammatical in isolation, but the system will merge them such that there is a problem. Original sentence: "There were two people present: Bob and Alice". Parallel edit 1: "There were three people present: Bob, Alice and Eve." Parallel edit 2: "There were three people present: Carlos, Bob and Alice." Seamlessly integrated, "self-healed", "robust" result: "There were three people present: Carlos, Bob, Alice and Eve".
  - skybrian 11y ago
    This is just moving the goalposts. Google Docs doesn't prevent this and nobody considers it a bug. Heck, a single-user textarea box doesn't prevent you from making this sort of logic error yourself (I do it all the time) and nobody considers it a bug. "Robust" and "self-healing" in this case are with respect to network faults and browser bugs that cause bizarre behavior that can confuse users.