Of course, you can frame the debate the other way around, i'm just making the point that "permissive/restrictive" means very little in this context and what matters really as a question is "do you wish huge corporations to benefit from your free-software work and expand on it to develop their own business, without EVER contributing anything back"? If yes, choose MIT and you'll probably regret it like so many open-source maintainers. Otherwise, choose (a)GPL and you probably won't regret it (at least i've never met someone so far who regretted choosing copyleft for their works, but it may exist of course).
I like the simplicity of this! But is it at all problematic if something changes early in the file and all the subsequent blocks boundaries shift causing many new blocks to be created?
rsync uses a sliding window to handle this situation. The implementation would be more complicated, but have you considered using librsync internally?
Let me explain where the 100 MB window comes from as its not only related to the upcoming compression implementation. Some graphic applications touch the timestamps of their files for no reason, making it harder to detect if a file changed. But some file formats always change their 'header' or 'footer'. Means, comparing the hash of the first or last 100 MB of a file that is 8GB in size gives a great performance boost to detect if a file got modified.
If you create a block every Xmb... inserting a single byte at the beginning of the file will change every subsequent block.
For 3d, to take Blender as an example, a zero-level diff feature would be to export (e.g. as glTF) and show which scene objects differ (meshes, textures, lights, etc.) More detailed parsing would give more details, e.g. image-diffing modified textures.
As I noted, merging is nontrivial. But it seems important -- if I save a branch, go back to the trunk and do more work, how do I add in the changes I made on the branch? Or even know what those changes were? Good diffs would help of course.
Merging would certainly have to be product-specific. For some open-source tools one could imagine hooking into their undo/redo logic, or parsing the product files into a temporary line-based format, but from outside it seems much more challenging than line-based merge in git (which is already imperfect for many applications).
About merge operations: The majority of solo artists and designers don't work in many branches. Most projects just go forward and branches are only useful if a rollback is needed. That being said, Snowtrack does offer a simplified "cherry-pick". But merge operations as you might know them from Git/Perforce are not implemented yet as it takes time to see how users adapt the software.
Keep in mind, most artists and designers are new to VCS or have never heard of it before and therefore it is crucial to find the right balance between too little and too many features. Any second that keeps the artist away from creating their artwork is wasted and therefore and the goal is to not interfere with their workflow or to add additional "management tasks"
https://www.mercurial-scm.org/wiki/LargefilesExtension
Since, last time i looked into it, which was a while ago, that was the best option for this.
/s
Looking at Fossil's delta code it uses 16 byte blocks and a sliding window when finding deltas:
https://fossil-scm.org/home/file?ci=trunk&name=src/delta.c&l...
This was only a means to an end though - it’s clear deeper integration with these products works better for a number of reasons, and a much better collaboration workflow isn’t just sending entire directories around. Look at Figma for an example of that - they reinvented the entire product space around collab.
Eventually the company (https://gobbler.com/) pivoted the business model away from this space into plugins.
I’m not convinced the opaque file approach can provide / capture enough value to be a sustainable business over the next 5-10 years.
Also a means to an end given the current sad reality. But most vendors are slowly moving towards better VCS support.
Since the HN headline says "3D artists" I was expecting to see an app that has a 3D viewer that can show 2 versions of a 3d scene on top^W^W inside each other and you can see toggle to see the differences...
Is this an abbreviation or a reference to a command or what does it mean?
Ctrl-W is delete previous word on some terminals, so I wrote "3d scene on top [of] each other" and decided saying "3d scene inside each other" made more sense.
Unless I am mis-understanding this is only a solution for organizing local files? Ideally there would be a distributed version control component or integration with an existing version control system. I can see this lulling users into a false sense of security that their local data is backed-up and safe.
If you're willing to make it a proper donation-run project with a commitment to free-software, i'm sensing a great future like GIMP/Blender has :) Good luck on it, can't wait to try it out once it's packaged on Debian
When writing a song with someone else, this can become really handy, as we sometimes don't know if some idea might work.
I would totally be a customer (if its not bound to a monthly payment). But as of now, it's lacking linux support (why do I have to be that special unicorn all the time?).
By the way: BandLab has something like this integrated already, but I want to use my own DAW.
1: https://en.wikipedia.org/wiki/MacOS_version_history#Version_...
Auto-commit is neat.
"Snowtrack is based on our open-source community project": https://github.com/snowtrack/snowfs
