The ones I was referring to for performance are:
- Support for instant snapshots
- Support for instant rollback
About alternatives, Perforce and PlasticSCM are currently commonly used. But I understand your objections, and will check if I can handle certain things differently in the README. Thanks again for your input!
I just think things like this can be impactful to perceptions of the work done on efforts such as Git-LFS, and describing things based on their own merits is often a better approach than pointing out lack elsewhere.
A VCS UI for design is something I've been looking for for a LONG time, so I signed up to the SnowTrack public beta immediately. I was just a little confused/concerned to learn it won't have a widely-supported backend to ease things such as synchronisation across devices, sharing resources via a hosted service, etc. Curious to see how this gets handled in the final product.
I learned a lot during the development of SnowFS and the open-source-community is the best place to share my experiences, that's why I put it on GitHub. At the end, I would be super happy if these insights can make it over to Git and Git-LFS.
We have a Discord channel, you are very welcome to swing by anytime for a virtual beer :-)
> The main requirement is performance (a missing point in your list)
The points I listed are not selected by me! I listed all the points in the project README verbatim. Other than the 2nd-to-last point (slow binary mod detect), performance wasn't otherwise listed in the README, so I don't know why you're calling me out for omitting it.
> If Git would be a good candidate as a versioning system for DCC software packages, it would have been picked up by now
You seem to be implying something else was picked up instead of Git? Other than SnowFS (which you say is in early alpha), what else has surpassed Git in this space? If nothing else has yet been picked up in place of Git, this argument isn't applicable.
> The commit hash integrity is a problem in CG/VFX productions, so is the 4GB limitation, as well as the I/O performance for large binary files
You seem to be again comparing SnowFS to Git-without-Git-LFS (other than the 4GB limitation which I already addressed in my comment). This is, as I said, disingenuous. Why keep making this selective comparison?
> P.S. Certain features and technical solutions will be feature-proposed to libgit2
That's cool, and I wish them the best of luck with developing these solutions. As I said, I've no issue with SnowFS; new approaches are always cool. I just think their listed justification is disingenuous; they'd be better of simply stating they want to develop something new and leave it at that.