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.
The only two things mine might do better are large binary files (because I do think they belong in version control) and decentralization.
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.
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
[2]: https://gavinhoward.com/2023/02/a-git-sin-re-signing-an-enti...
Alright you got me, I'm listening
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.
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.
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-t...
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.
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.
Good luck !
Native UI will be much harder...
Thank you!
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-1000...
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")
And I am aware of the combination problem, and there will be the option to lock things.
But when it comes to visual things, someone does have to stare at it. If you watch https://youtube.com/watch?v=iZre2MUyvoQ , the thing you should notice is that John Lasseter is constantly checking the integration of separate parts.
A director might tell a modeler and a designer to work on the same scene at the same time, as you said. In that case, I kinda expect the director to check the integration.
Binary files are harder because there is no integration test, yes. But integration tests don't catch everything in code either, and people still want automatic merges.
Edit: can’t find it anywhere?
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.