Re:Lies I was told about collab editing, Part 1: Algorithms ...
by Onavo on Friday December 06, 2024 @04:02PM
(#42344405)
> Users should then be presented with those conflicts - and it could even be completely visual. Being able to scrub through history also seems like a viable alternative
I think "Git" would be a wonderful name for this type of CRDT.
Re:Lies I was told about collab editing, Part 1: Algorithms ...
by satvikpendem on Friday December 06, 2024 @04:15PM
(#42344529)
I mentioned Loro in another comment, but they actually do conflict resolution on top of Git trees [0]. Jujutsu is also interesting but I'm not sure if they do any conflict resolution [1].
Re:Lies I was told about collab editing, Part 1: Algorithms ...
by drdaeman on Friday December 06, 2024 @04:06PM
(#42344445)
More like Pijul or Darcs?
Git is popular, but it's not particularly great at conflict resolution.
Re:Lies I was told about collab editing, Part 1: Algorithms ...
by Etheryte on Friday December 06, 2024 @06:38PM
(#42345806)
For all things Git is good at, conflict resolution is most definitely not one of them. There are many ways to slice a conflicting diff into plus and minus parts, and somehow Git usually manages to create conflicts that are the least human readable. We live in an era of widely adopted and universal language servers, yet Git pretends that every change is just a char added or removed. There are many tools out there which do a considerably better job at this, for example by diffing the AST, not the text representation.
Re:Lies I was told about collab editing, Part 1: Algorithms ...
by Wowfunhappy on Friday December 06, 2024 @07:47PM
(#42346219)
Hi, I'm a hobbyist coder with lots of personal forks of open source projects. I frequently spend a lot of time merging in changes from upstream. Can you suggest tools that would help with this?
Re:Lies I was told about collab editing, Part 1: Algorithms ...
by CGamesPlay on Saturday December 07, 2024 @01:35AM
(#42347729)
Things get way nastier when you start considering trees, e.g. yJS operates on JSON documents. From a UI standpoint (where the UI is showing some shallow level and hasn't been expanded to the deeper level) users could never even see edits that have been deleted.
I think that the class of CRDTs that preserve conflicts (IIRC that is when a register can hold multiple values) hold the most promise. Users should then be presented with those conflicts - and it could even be completely visual. Being able to scrub through history also seems like a viable alternative (allowing the user to figure out how a strange thing happened, or how their changes disappeared).