5 ms·

Well, shoot. I am working on a new VCS too, and Grace seems to have most of what I want in mine. The only two things mine might do better are large binary file

Well, shoot. I am working on a new VCS too, and Grace seems to have most of what I want in mine. The only two things mine might do better are large binary files (because I do think they belong in version control) and decentralization.

lagniappe 2y ago
> The only two things mine might do better are large binary files (because I do think they belong in version control) Alright you got me, I'm listening
- gavinhoward 2y ago
  Ah, didn't expect interest. I want to track changes to binary files the way we do with text. [1] For example, if you have a PNG texture, my VCS will track changes at the pixel level. If you have a Blender file, it will track changes at the item level, from meshes to materials and vertices, and everything in-between. Yes, it will be a lot of manual work to implement each file type, but that's how I plan to make money. [1]: Only files that use lossless compression, of course.
  - albertzeyer 2y ago
    Interesting idea. I assume with quite a number of technical difficulties (even despite the manual work for each file type). However, I don't think making money from this will work. A new version control system must be 100% open source. Otherwise it will not be an option for most people. Even when only selling extensions for certain file types and keeping the core open source, I don't think this will work, as you keep away the main interesting feature then.
    - gavinhoward 2y ago
      FWIW, I think you are absolutely right. However, my target audience isn't developers; my target is users of Perforce, which is closed source. So I think a source available [1] VCS will be palatable for that audience. I could be wrong, though. [1]: https://gavinhoward.com/2023/12/is-source-available-really-that-bad/ https://gavinhoward.com/2023/12/is-source-available-really-t...
      - gardaani 2y ago
        Diversion is already targeting users of Perforce and game developers storing large binary files. Diversion is currently closed source, but may open source their platform in the future. https://news.ycombinator.com/item?id=39088551 https://news.ycombinator.com/item?id=39088551
        gavinhoward 2y ago
        Thank you for letting me know.
      - muststopmyths 2y ago
        As a games industry (where Perforce is by far the most common VCS in a team of any reasonably significant size) person, we absolutely do not give a crap about source-available or otherwise. We want tools that work, even if we have to pay for them. None of us have time to delve into the workings of a source control system to troubleshoot problems instead of working on our .. work. Sorry if it sounds harsh as that is not my intent. My suggestion is you spend much more time on making sure your system is reliable and has proper support (even if paid) instead. Bonus points for easy GUI interfaces that artists and designers can use without shooting themselves (and their team!) in the foot. No one loves Perforce, but it works well enough and nothing else come close to it for the games industry.
        gavinhoward 2y ago
        No offense taken, and you are absolutely right. Yes, it has to work first, and I intend to do that. And I surely will have paid support; that will be my bread and butter. I was also going to have a web UI through the browser or a TUI. I merely mentioned source available vs Perforce to show that my VCS could make money, if I made it right.
        muststopmyths 2y ago
        Ideally, you want a self-hosted mode (no cloud-only) and a native UI. Even if as stretch goals. We don't like our source, and more importantly assets, hosted outside our control and native UIs are just better. Good luck !
  - johannes1234321 2y ago
    Isn't that "simply" a task for the diff viewer? - VCSs like git treat all files like objects (while storage does some deduplication) and only few things imply textual content, and I wouldn't want an automated merge on an image or 3D scene anyways (while in rare cases this might work, I guess more often it would produce more trouble than where it helps)
    - gavinhoward 2y ago
      Properly tracking changes would allow less disk space to be used. xdelta is not supposed to be used on compressed data [1], but my VCS will handle that transparently using less space. You are right to be nervous about auto merges, and that will be the biggest work when implementing support for a file type. But I think it is possible in many cases. For example, Blender files store everything in one file. You can reference things between files, and people do that, but often, you will still want to store the material for a mesh with the mesh. If someone changes the mesh, and someone else changes a material, those changes should automerge. [1]: https://github.com/jmacd/xdelta/issues/193#issuecomment-100025553 https://github.com/jmacd/xdelta/issues/193#issuecomment-1000...
      - johannes1234321 2y ago
        One of the (many) major improvements of git over CVS was that CVS stored diffs., while git (not on lowest, but practicalblaxer) stores the full files. Depending on diffs made it hard to jump between versions (need to calculate the intermediate steps for any operation) while tracking full files made it possible that git could track changes even over files, thus in some cases it can even merge when code is moved between files. And for the merge: Even the "simple" merge you describe will likely lead to issues when a designer worked on improving surface to make a scene look "right" while somebody else changes the scene and the merge then goes somewhat unseen. And for that kind of stuff you don't have any unit tests as at least a safety net, as you have with code ("it compiles and tests pass - the merge didn't break anything fundamental")
        gavinhoward 2y ago
  - globular-toast 2y ago
    So not treating them as binary files! Would you provide an interface so application developers can provide their own plugins for their file types?
    - gavinhoward 2y ago
      Yes.
  - _lvbh 2y ago
    Thank you! I read your comment yesterday and forgot about it, then today morning, suddenly realized I needed to version control a bunch of sound files (which aren’t getting pushed up to any “cloud”) and remembered this. Will check it out. Edit: can’t find it anywhere?
    - gavinhoward 2y ago
      It doesn't fully exist yet. Mine is far behind Grace. That's why I began with, "Well, shoot," because Grace beat me to the punch. Sorry. But with Grace existing, I am not sure I should continue. If I do, I can contact you when it's ready, if you wish.
      - _lvbh 2y ago
        I can’t really use grace since it’s centralized. Will wait for when yours come out
SBArbeit 2y ago
Hi! Which one are you working on? (I created Grace.) I'd love to chat... I've spoken to the creators of several other VCS's, it's a nice group of people. Hit me up on Twitter or whatever, I'd love to hear what motivated you, and what you're solving for.
- gavinhoward 2y ago
  You don't know about it because it is far behind Grace. One of my motivations is hatred of Git, but unfortunately, I hate CMake more, so I wrote a build system first that I literally just released a month ago. [1] So I am rightfully unknown to other VCS creators. Also, I hate Git despite being one of the 20% that know 80%. I have done things with Git that no one should do. [2] [3] Another of my motivations is vendor lock-in. Yes, Git is decentralized, but it doesn't include everything people want for repos, such as issue trackers. These things are what GitHub, GitLab, and others use to lock users in. Mine will follow Fossil and peovide everything, so users can switch providers easily. So I strongly disagree with your cloud-first design. My third motivation is binary files. Why don't we track them better? I mean, yeah, xdelta is cool, but we could do so much better. [1]: https://news.ycombinator.com/item?id=39904895 https://news.ycombinator.com/item?id=39904895 [2]: https://gavinhoward.com/2023/02/a-git-sin-re-signing-an-entire-git-repo/ https://gavinhoward.com/2023/02/a-git-sin-re-signing-an-enti... [3]: https://gavinhoward.com/2023/07/how-i-made-a-monorepo/ https://gavinhoward.com/2023/07/how-i-made-a-monorepo/
thfuran 2y ago
If they're used by the software and aren't deterministically producible by the code, then I don't really understand how anyone could say that they don't belong.
- gavinhoward 2y ago
  Exactly.

lagniappe 2y ago

> The only two things mine might do better are large binary files (because I do think they belong in version control) Alright you got me, I'm listening

gavinhoward 2y ago
Ah, didn't expect interest. I want to track changes to binary files the way we do with text. [1] For example, if you have a PNG texture, my VCS will track changes at the pixel level. If you have a Blender file, it will track changes at the item level, from meshes to materials and vertices, and everything in-between. Yes, it will be a lot of manual work to implement each file type, but that's how I plan to make money. [1]: Only files that use lossless compression, of course.
- albertzeyer 2y ago
  Interesting idea. I assume with quite a number of technical difficulties (even despite the manual work for each file type). However, I don't think making money from this will work. A new version control system must be 100% open source. Otherwise it will not be an option for most people. Even when only selling extensions for certain file types and keeping the core open source, I don't think this will work, as you keep away the main interesting feature then.
  - gavinhoward 2y ago
    FWIW, I think you are absolutely right. However, my target audience isn't developers; my target is users of Perforce, which is closed source. So I think a source available [1] VCS will be palatable for that audience. I could be wrong, though. [1]: https://gavinhoward.com/2023/12/is-source-available-really-that-bad/ https://gavinhoward.com/2023/12/is-source-available-really-t...
    - gardaani 2y ago
      Diversion is already targeting users of Perforce and game developers storing large binary files. Diversion is currently closed source, but may open source their platform in the future. https://news.ycombinator.com/item?id=39088551 https://news.ycombinator.com/item?id=39088551
      - gavinhoward 2y ago
        Thank you for letting me know.
    - muststopmyths 2y ago
      As a games industry (where Perforce is by far the most common VCS in a team of any reasonably significant size) person, we absolutely do not give a crap about source-available or otherwise. We want tools that work, even if we have to pay for them. None of us have time to delve into the workings of a source control system to troubleshoot problems instead of working on our .. work. Sorry if it sounds harsh as that is not my intent. My suggestion is you spend much more time on making sure your system is reliable and has proper support (even if paid) instead. Bonus points for easy GUI interfaces that artists and designers can use without shooting themselves (and their team!) in the foot. No one loves Perforce, but it works well enough and nothing else come close to it for the games industry.
      - gavinhoward 2y ago
        No offense taken, and you are absolutely right. Yes, it has to work first, and I intend to do that. And I surely will have paid support; that will be my bread and butter. I was also going to have a web UI through the browser or a TUI. I merely mentioned source available vs Perforce to show that my VCS could make money, if I made it right.
        muststopmyths 2y ago
        Ideally, you want a self-hosted mode (no cloud-only) and a native UI. Even if as stretch goals. We don't like our source, and more importantly assets, hosted outside our control and native UIs are just better. Good luck !
- johannes1234321 2y ago
  Isn't that "simply" a task for the diff viewer? - VCSs like git treat all files like objects (while storage does some deduplication) and only few things imply textual content, and I wouldn't want an automated merge on an image or 3D scene anyways (while in rare cases this might work, I guess more often it would produce more trouble than where it helps)
  - gavinhoward 2y ago
    Properly tracking changes would allow less disk space to be used. xdelta is not supposed to be used on compressed data [1], but my VCS will handle that transparently using less space. You are right to be nervous about auto merges, and that will be the biggest work when implementing support for a file type. But I think it is possible in many cases. For example, Blender files store everything in one file. You can reference things between files, and people do that, but often, you will still want to store the material for a mesh with the mesh. If someone changes the mesh, and someone else changes a material, those changes should automerge. [1]: https://github.com/jmacd/xdelta/issues/193#issuecomment-100025553 https://github.com/jmacd/xdelta/issues/193#issuecomment-1000...
    - johannes1234321 2y ago
      One of the (many) major improvements of git over CVS was that CVS stored diffs., while git (not on lowest, but practicalblaxer) stores the full files. Depending on diffs made it hard to jump between versions (need to calculate the intermediate steps for any operation) while tracking full files made it possible that git could track changes even over files, thus in some cases it can even merge when code is moved between files. And for the merge: Even the "simple" merge you describe will likely lead to issues when a designer worked on improving surface to make a scene look "right" while somebody else changes the scene and the merge then goes somewhat unseen. And for that kind of stuff you don't have any unit tests as at least a safety net, as you have with code ("it compiles and tests pass - the merge didn't break anything fundamental")
      - gavinhoward 2y ago
- globular-toast 2y ago
  So not treating them as binary files! Would you provide an interface so application developers can provide their own plugins for their file types?
  - gavinhoward 2y ago
    Yes.
- _lvbh 2y ago
  Thank you! I read your comment yesterday and forgot about it, then today morning, suddenly realized I needed to version control a bunch of sound files (which aren’t getting pushed up to any “cloud”) and remembered this. Will check it out. Edit: can’t find it anywhere?
  - gavinhoward 2y ago
    It doesn't fully exist yet. Mine is far behind Grace. That's why I began with, "Well, shoot," because Grace beat me to the punch. Sorry. But with Grace existing, I am not sure I should continue. If I do, I can contact you when it's ready, if you wish.
    - _lvbh 2y ago
      I can’t really use grace since it’s centralized. Will wait for when yours come out

SBArbeit 2y ago

Hi! Which one are you working on? (I created Grace.) I'd love to chat... I've spoken to the creators of several other VCS's, it's a nice group of people. Hit me up on Twitter or whatever, I'd love to hear what motivated you, and what you're solving for.

gavinhoward 2y ago
You don't know about it because it is far behind Grace. One of my motivations is hatred of Git, but unfortunately, I hate CMake more, so I wrote a build system first that I literally just released a month ago. [1] So I am rightfully unknown to other VCS creators. Also, I hate Git despite being one of the 20% that know 80%. I have done things with Git that no one should do. [2] [3] Another of my motivations is vendor lock-in. Yes, Git is decentralized, but it doesn't include everything people want for repos, such as issue trackers. These things are what GitHub, GitLab, and others use to lock users in. Mine will follow Fossil and peovide everything, so users can switch providers easily. So I strongly disagree with your cloud-first design. My third motivation is binary files. Why don't we track them better? I mean, yeah, xdelta is cool, but we could do so much better. [1]: https://news.ycombinator.com/item?id=39904895 https://news.ycombinator.com/item?id=39904895 [2]: https://gavinhoward.com/2023/02/a-git-sin-re-signing-an-entire-git-repo/ https://gavinhoward.com/2023/02/a-git-sin-re-signing-an-enti... [3]: https://gavinhoward.com/2023/07/how-i-made-a-monorepo/ https://gavinhoward.com/2023/07/how-i-made-a-monorepo/

thfuran 2y ago

If they're used by the software and aren't deterministically producible by the code, then I don't really understand how anyone could say that they don't belong.

gavinhoward 2y ago
Exactly.