From the README:<p>> <i>Why not Git/Git-LFS, libgit2, or SVN?</i><p>> <i>Disadvantages:</i><p>> <i>(Without Git-LFS): Heavy cost with zipping, packing, and delta-compression for larger files</i><p>Given the caveat (without Git-LFS) it seems odd to include this in the list<p>> <i>If not properly tracked, binaries become accidentally part of "base" history</i><p>That's a big "if", and not an inherent problem. This could easily be resolved by any good design-focused UI (e.g. SnowTrack), so this seems a poor argument against using Git as a backend.<p>> <i>Removing older commits is cumbersome due to Gits commit hashing integrity</i><p>This (like the first bullet point) does not apply to Git-LFS.<p>> <i>Complicated rewriting history procedure</i><p>What?<p>> <i>Issues with binaries >4GB on Windows</i><p>A known bug in Git-LFS that they're working to fix. There are workarounds provided in the linked tickets (that could be leveraged by a UI / abstraction layer like SnowTrack).<p>This is the first item in the bullet list that is a real disadvantage of Git LFS, but the workaround for it seems much less effort than developing a new VCS backend from scratch.<p>> <i>Slow in binary modification detection</i><p>I'm not sure if this applies to Git or Git LFS; there's little detail provided. But if it's significant, this is probably the only really compelling disadvantage listed.<p>> <i>Git uses a restrictive license</i><p>And finally we see the real reason for not using Git.<p>---<p>NOTE: I don't mean to make out that building an alternative VCS to Git is not worth pursuing. Nor that it needs any specific justification. Just that listing a justification that seems (to me) mostly disingenuous is worth pointing out.
This is great, well done. While at (now defunct) Dotscience we did a lot of work on Dotmesh which you might find interesting: <a href="https://github.com/dotmesh-io/dotmesh" rel="nofollow">https://github.com/dotmesh-io/dotmesh</a><p>I would also look at data science/ML as a potential use for the tool as there are real issues with using Git for training data.<p>Last point which is more of a tip: Show don’t tell. If you did some side by side workflow walkthroughs showing the difficulties with other tools it will make it easier for people to see that this problem is real (which it definitely is)
But what if I have software <i>and</i> images (e.g. as in game software)? Which version control system do I use?<p>Honestly, I think the effort was better spent on an improved version of Git.
Very interesting. I'd like to learn more about how it works. How does this compare to DVC[1], for instance?<p>I'll throw in a shameless plug for my tool in this area, Dud[2]. Dud is to DVC what Flask is to Django.<p>Are the mentioned benchmarks published somewhere?<p>[1]: <a href="https://dvc.org" rel="nofollow">https://dvc.org</a>
[2]: <a href="https://github.com/kevin-hanselman/dud" rel="nofollow">https://github.com/kevin-hanselman/dud</a>
There is a somewhat related discussion going on about Pijul’s suitability for use with game editors:
<a href="https://discourse.pijul.org/t/using-pijul-for-a-game-editor/729?u=erlend_sh" rel="nofollow">https://discourse.pijul.org/t/using-pijul-for-a-game-editor/...</a>
JavaScript[0] isn't what I would call a fast storage repository, but I guess it works out for prototyping.<p>On the context of porting to C and C++, or make it execute faster, I can see two options with minor rewrites.<p>Use AssemblyScript and generate native code via WebAssembly AOT compilers.<p>Try to adapt TypeScript to C++ compiler from Microsoft's MakeCode project.<p>Implement your own C++ code generator.<p>It would be much easier than keep using multiple code bases in parallel, plus any memory corruption issues would be most likely bugs on the code generator.<p>[0] - Yes I know the source code is Typescript.