I'm which case dvcs will always be useless: this is a speed of light AND network partition issue. If you don't care about distributed vcs then the issue has been cracked for decades: the likes of TFS have file locking.
Pijul has one of the most reasonable approaches to conflicts: you solve them once. That is about as close to cracked as we can get for dvcs in this universe.
What I was trying to say is in regards to the artist/lawyers (let’s generalize this to anyone who does not know how to code or could not meaningfully interpret a plain text or binary diff of a certain document type), you can have a user friendly dvcs that has structured conflicts but you need that system to understand more than plain text/the file system. It needs to know the schema of the thing it is merging to be meaningfully diffable or perform three way merges.
What I mean by structured conflicts is conflicts that do not break the editor’s interpretation of the document state. When you’re writing source code in vim/whatever IDE you use, the editor state is entirely decoupled from the runtime of your merge conflicts (git and vim do not need to know the semantics of the programming language you are writing source code in to work), so a syntax error in a merge conflict doesn’t prevent you from fixing the syntax error or resolving the conflict. The trickiness to structured version control is that the merge conflicts must be resolvable within whatever is serving as a medium of editing the document. So in structured editors, you can have conflicts in a document but they have to still be semantically interpretable while in a conflicted state.
This is not possible in pijul/git or any generic file based vcs without an editor that can be provided a schema to interpret the document type it is merging. Sure you can write your own diff and merge drivers but this becomes cumbersome fast and is extremely uninteroperable.
However, this is entirely possible, I’ve been working on a system that does this very thing for a year. Happy to show you if you want to see.
I think the bigger question is Why on earth would you would want a dvcs like this to exist when you have plenty of centralized version control systems to cater to people who aren’t technical?
Philosophically there are quite a few people who care about not having their work gated by subscription plans/centralized players. I’m relatively indifferent to that side of things but I do like having local access to all my documents.
The bigger thing to me is that it allows non-technical people to do work that can be used to generate semantically correct code. The document types themselves can also interoperate, which makes things like centralizing static asset generation very useful if you share assets across multiple client codebases. This also means you can let a copy translator, do things like create rich text translations without needing them to edit things like a stings.xml or a .po file and worry about them botching syntax. Designers can put all icons into a document and generate themes and palette code for engineers to consume that work across any client type. Sure you can do all those things in isolation with centralized software providers but without a commit sha to point to, these tools become kind of unviable to engineers since they aren’t idempotent (or offline first). Moreover many code generation tasks end up becoming very product and organization specific, so the system needs to provide a generalized way for anyone to create their own diffable document type.
I think there’s a host of other benefits gained but my motivations for the tool I made came from problems that arose at my first company when dealing with translations, feature flags and building a good dark mode. I also think merging is the best way to handle collaborative editing and there is little reason aside from the syntax errors that arise in plain text conflicts for the general concept of dvcs to only be accessible to software engineers.
Sorry for ranting. Hope that clarifies what I meant.