3 ms·
I don't agree with that framing... When you say "cache coherency" you're implicitly assuming some authoritative state. The point of git is that there isn't a s
by chubot 6y ago
I don't agree with that framing... When you say "cache coherency" you're implicitly assuming some authoritative state. The point of git is that there isn't a single authoritative state.
Not all apps will work with that model, but more apps than you think would.
I guess the difference is how fine-grained you want the updates to be. For example something like Figma in the browser (a collaborative photoshop) implements a lot of custom application-specific sync with CRDTs and so forth.
Maybe you need the really fine-grained updates, or maybe you just need some Github-like site which allows coarse-grained collaboration.
In other words, there can be a network model between "e-mail a .PSD file" and Figma. I think this "in between" would scale to more applications than reinventing sync inside every app. Imagine audio editors, video editors, 3D modellers, etc. Rewriting all those in the style of Figma is prohibtive.
I would rather have open file formats and application-agnostic sync, like git. And I think it's a lot cheaper to develop, although current software business models don't really support its development.
- Someone 6y ago“The point of git is that there isn't a single authoritative state.“ I think you’re missing the point of the post you refer to. For git, there _technically_ isn’t a single authoritave state, but for many, if not most, git use cases, there _sociologically_ is. Projects typically have one repo that is _the_repo_: the repo most merges are done to, that releases get built from, whose url you give when you tell people where the project lives, etc. All other clones of that repo, sociologically, are just caching the main repo and changes you make. Then, humans have to decide when to flush what part(s) of the write cache to the main server, and when that results in conflicts, humans have to resolve them. That’s, I think, what “which manages to push all the coherency issues onto the user” means.
- gumby 6y agoYou are correct, I meant that even in a peer-peer merge (which can even be just one person debugging the same program on both a Mac and a Linux machine), any merge conflicts are marked and left for the user to decide about.
- chubot 6y agoThe presence of useful forks means that there isn't a single authoritative state. For example, I've had a fork of bash-completion for a over a year, and I use it all the time. How do I fork a Google doc? At best you can copy and modify, but here's no merge. Merging is a feature, not a bug (maybe not for all applications, but 99% of them).