4 ms·

I really like the idea of a version control system based on commutative patches but I'm just not seeing how it's going to translate to a system that's intuitive

I really like the idea of a version control system based on commutative patches but I'm just not seeing how it's going to translate to a system that's intuitive and easy to use not just for programmers, but also for lawyers and artists. Consider a patch like this one, titled "Solving conflicts": https://nest.pijul.com/pijul/pijul/changes/2MLOE3FPVT4ZXC4L74VC7GV2IXATZQNFLJECDPZZ7MTSW4A6XT5QC https://nest.pijul.com/pijul/pijul/changes/2MLOE3FPVT4ZXC4L7... "Solving an order conflict" and "Resurrecting zombie bytes" sound like the tricky parts of the patch-based workflow. I would very much like to understand how to work with these parts of Pijul. How are these actions performed? How does the user interact with the graph to perform these actions? Is the conflict state rendered into the file? It's not mentioned in the video, and I cannot find it in the documentation or in blog posts. I cannot be the only one that's interested in learning about those things, and I think it would be more effective than anything else in raising interest for Pijul. My best guess is that the workflow is still rough around the edges and requires the user to have a good understanding of the underlying graph, and therefore it's not ready to be presented yet. And my hot take is that it's still rough around the edges because there is no easy way, and maybe no way at all, to make it polished and intuitive for a new user. But I want to be proven wrong.

jsunderland323 3y ago
I’d be happy to demo a work in progress if you want to see a structured dvcs. This is a surprisingly tricky problem. There’ve been quite a few attempts throughout the years at a structured/visual dcvs but it’s almost impossible to solve without also building a schema language, an offline browser, and a package manager/app registry. There’s murmurs in some of the offline first/CRDT communities that suggest other solutions but I haven’t seen anything structured and viable emerge. Anyway, let me know if you want to chat. I’ll put my email in my bio
kadoban 3y ago
Is git conflict resolution "intuitive and easy to use not just for programmers, but also for lawyers and artists"? Several programmers I know can barely manage it. I think we might be setting our bar a little high here.
- jsunderland323 3y ago
  Yes. That’s the whole problem. If you don’t crack that it’s useless
  - kadoban 3y ago
    Hmm, that doesn't really seem fair. That's _a_ problem, and an incredibly difficult one. There are several other problems though, with git and other contemporaries that one could try to usefully solve.
    - jsunderland323 3y ago
      Sorry, I was replying in the context of GP’s original comment with regards to general accessibility. Agreed git has a lot of other problems.
      - kadoban 3y ago
        Ah, fair. Sorry, I bet I missed the context.
  - zamalek 3y ago
    > If you don’t crack that it’s useless 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.
    - jsunderland323 3y ago
      I think I really needed to add more context to this comment. This is on me, again sorry. I was really saying this in regards to the part of the comment regarding dvcs and general accessibility. 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.

jsunderland323 3y ago

I’d be happy to demo a work in progress if you want to see a structured dvcs. This is a surprisingly tricky problem. There’ve been quite a few attempts throughout the years at a structured/visual dcvs but it’s almost impossible to solve without also building a schema language, an offline browser, and a package manager/app registry. There’s murmurs in some of the offline first/CRDT communities that suggest other solutions but I haven’t seen anything structured and viable emerge. Anyway, let me know if you want to chat. I’ll put my email in my bio

kadoban 3y ago

Is git conflict resolution "intuitive and easy to use not just for programmers, but also for lawyers and artists"? Several programmers I know can barely manage it. I think we might be setting our bar a little high here.

jsunderland323 3y ago
Yes. That’s the whole problem. If you don’t crack that it’s useless
- kadoban 3y ago
  Hmm, that doesn't really seem fair. That's _a_ problem, and an incredibly difficult one. There are several other problems though, with git and other contemporaries that one could try to usefully solve.
  - jsunderland323 3y ago
    Sorry, I was replying in the context of GP’s original comment with regards to general accessibility. Agreed git has a lot of other problems.
    - kadoban 3y ago
      Ah, fair. Sorry, I bet I missed the context.
- zamalek 3y ago
  > If you don’t crack that it’s useless 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.
  - jsunderland323 3y ago
    I think I really needed to add more context to this comment. This is on me, again sorry. I was really saying this in regards to the part of the comment regarding dvcs and general accessibility. 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.