The biggest problem that I ran into with this approach however was checkpointing. I could never correctly reason about a way to prune the log of updates that you apply that still allows (100% correct, intent-preserving) merges from someone that might have been offline since the dawn of time. Does anyone know if this issue with this approach was ever solved?
I'm not sure it is universally possible, because you never know where somebody might branch from.
I think checkpointing only can be effectively done with reliable consistency when you know everybody are onboard and stick to the same shared checkpoints, in your shared past (checkpoints you know they know), because otherwise they might themselves not know any checkpoint identical to one of yours when you'll merge.
It's bad in particular when you're merging files that your algorithm only can parse as bit strings, not data structures, as the entire structure can have been very drastically changed with no clear indication of what went where. If there's known structures in common, at least you can attempt some kind of logical reasoning.
Somebody forking in the middle of a full rewrite with no existing checkpoints that's coming back to a document now with a checkpoint before and after it would then have to have a history going back to the older checkpoint (the exact same version!), merge backwards, and merge then against the diffs to the new checkpoint, and forwards to the current version.
If your most similar stored versions (with diff history) of the same document in your separate histories are far apart, it WILL be painful to merge.
I think checkpointing only can be effectively done with reliable consistency when you know everybody are onboard and stick to the same shared checkpoints, in your shared past (checkpoints you know they know), because otherwise they might themselves not know any checkpoint identical to one of yours when you'll merge.
It's bad in particular when you're merging files that your algorithm only can parse as bit strings, not data structures, as the entire structure can have been very drastically changed with no clear indication of what went where. If there's known structures in common, at least you can attempt some kind of logical reasoning.
Somebody forking in the middle of a full rewrite with no existing checkpoints that's coming back to a document now with a checkpoint before and after it would then have to have a history going back to the older checkpoint (the exact same version!), merge backwards, and merge then against the diffs to the new checkpoint, and forwards to the current version.
If your most similar stored versions (with diff history) of the same document in your separate histories are far apart, it WILL be painful to merge.