<br><div class="gmail_quote">On Wed, Jul 14, 2010 at 10:43 PM, iberlynx <span dir="ltr"><<a href="mailto:iberlynx@lavabit.com">iberlynx@lavabit.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi,<br>
<br>
you say git is not the way to go because you only consider it in the pessimistic approach. But have you thought of using git or some similarly powerful diff engine with an optimistic approach?<br>
<br></blockquote><div>What I am saying is that a git based solution needs the pessimistic approach to work. See below:<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

Let me give you my proposal:<br>
Every user action be it a single character change or a block change or a formatting change is automatically git-committed and git-pushed to the other users, which would automatically git-merge the changes as git does so well. So no locking would be required, hence no latency problem.<br>

(This would additionally solve the problem you stated with non atomic changes!)<br>
The only obstacle that I foresee is that IIRC git doesn't merge changes on the same line, but I'm sure that there's a way to tailor git's algorithm for this specific use-case!<br>
<br>
Am I just being my usual self, and this is a crazy idea? Or does it make sense to you as well?<br>
<div><div></div><div class="h5"><br></div></div></blockquote><div>The problem is that git merge works pretty well when the original state of the merged documents are the same (or at least very similar). It requires that a particular line can be found (if not at the indicated position) by comparison of the surrounding lines, if it cannot find (or does not have) this "context", then the merge fails.<br>
Using an optimistic approach environment, it is guaranteed that the state of each local replica are different, because the local changes are incorporated straight away in the document. This means that, for the very vast majority of the editing actions (actually down to each key stroke), you will have the following done on each of the other replicas:<br>
a git merge is processed, which could have to scan the document around the specified line number (if the local editor added a line before). Now:<br>If the local editor modified the same line, or the scan above did not succeed, we have a merge conflict. In case of a merge conflict, git needs it to be manually solved in order to complete the merge operation.<br>
Now keep in mind that until the merge request is fully processed, the local user cannot continue his own editing (because the git commit cannot be done). Also keeping in mind that as far as text processing is concerned, a line (in the git sense: everything until a new line char) is actually a full paragraph.<br>
So to sum-up: in case of git with the optimistic approach, you would be handling a lot of merge conflict between each of your key strokes. And even if there are no merge conflict, your user interface will be blocked during the whole merge operation of each of the other editor actions. While you feel that the git algorithm is really good, it is still way too slow to be acceptable in between key strokes of someone typing text.<br>
<br>There is a further problem, which actually also disqualify git (whatever the approach) when implementing real time collaboration on applications relying on position based textCursors (Qt scribe engine, but if I understood properly the blog posts, also Kate internal cursor stuff):<br>
Let's say your cursor points at position 10 of your text. A change from another editor is merged (let's say no merge problem happened), before that position. If the change modifies the char count, your position 10 becomes invalid and needs to be recalculated. In order to do this you could use the git diff to compute what the difference is. But doing this you are basically reconstructing what the operation was. Basically the workflow of your software would be: editing action -> state diff -> transmit state diff -> merge state diff -> compute editing action from state diff -> update cursor position.<br>
It is far more logical to transmit the editing actions.<br><br>Pierre<br><br></div></div><br>