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.
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.
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.
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.
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
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)
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.
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")
About diffs, that is true, but my VCS does not use diffs.
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.
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.
Alright you got me, I'm listening