VFSForGit VS juicefs

It's not only Windows that uses Git at Microsoft, but Sharepoint and Office (which includes the on-prem version of SharePoint). In terms of repo size Windows and Office are similar. I was part of the team that migrated Sharepoint from a Perforce clone to Git and helped build the tooling to allow Office to move as well. VFS for Git [1] and Scalar [2] are really good pieces of software.

[1] - https://github.com/microsoft/VFSForGit

[2] - https://github.com/microsoft/scalar

Congratulations! That means you basically figured out how the clone procedure works and found a way to do so just in a partial way (also in an unsafe way). But it is a cool idea, nonetheless.

Also check out the Scalar [1] project and its predecessor, GVFS [2], both from Microsoft to manage their monorepo via a VFS layer.

[1]: https://github.com/microsoft/scalar

[2]: https://github.com/microsoft/VFSForGit

VFS for Git is still Open Source: https://github.com/microsoft/VFSForGit

Microsoft's blog posts have indicated a move to use something as close to off-the-shelf git as possible, though. They say they've stopped using VFS much and are instead more often relying on sparse checkouts. They've upstreamed a lot of patches into git itself, and maintain their own git fork but the fork distance is generally shrinking as those patches upstream.

https://github.com/microsoft/VFSForGit

better than it used to, with the caveat that git in particular is not and has never claimed to be good at versioning blobs.

Oh dear you're not going to like this.

It’s virtualised file system: https://github.com/microsoft/VFSForGit, only downloads what you actually use. Same thing in every large company, but different implementations.

This is where something like VFSForGit[0] helps out. Instead of cloning the entire repo, it creates a virtual file system and fetches objects on demand. MSFT uses it internally for the Windows source tree (which now exceeds 300GB).

[0]: https://github.com/microsoft/VFSForGit

There's also a performance consideration. Not excluding /bin/ or /obj/ folders means dependencies are being tracked as well, and sometimes dependencies themselves are bigger than the program's source code itself. This is commonly the case with node projects, as the node_modules folder can balloon to hundreds of megabytes. They should never be tracked in git due to the nature of how git's internal database works. For e.g. if you delete a dependency because it's no longer needed, you can never fully reclaim that disk space (at least for the master branch) as git will need to keep the binary data stored in its internal tracking database because a previous commit in the master branch has captured the data. As you make more branches, git needs to store the data required to reconstruct your repo to a different state when you switch branches. When a branch has changes measured in the kilobytes, check out is very manageable, but when the differences balloon to many MBs due to the presence of heavy binary files, then checkout between different branches/commits can get very slow. Though, this happens anyway when source code data eventually reaches a certain threshold, beyond the hundreds of megabytes, it's made unnecessarily worse by including any binary files. It's one of the reasons Microsoft created VFS for git: https://github.com/microsoft/VFSForGit.

You mean like VFSforGit? Or the successor for that called Scalar? This has been a solved problem. Microsoft moved their entire Windows codebase to git. There have been a ton of huge improvements to performance as a result of that. And the above two plugins are easily better ways to deal with what you're referring to without resulting to dead tech.

Support for Kerberos keytab files

JuiceFS under the Apache License 2.0, is a high-performance POSIX file system optimized for cloud-native environments. It stores data in Object Storage (e.g., Amazon S3) and metadata in databases like Redis, MySQL, or TiKV. JuiceFS integrates massive cloud storage with big data, machine learning, and AI applications efficiently, akin to local storage. It features full POSIX and Hadoop compatibility, S3 interface, Kubernetes support, and shared file storage for numerous clients. Some cool features are - strong consistency, scalable performance, data encryption, global file locks, and compression with LZ4 or Zstandard.

To improve the handling process of capacity overrun, the JuiceFS client supports deletion operations in the case of Ceph cluster fullness (see related code changes in JuiceFS Community Edition). Therefore, for newer client versions, there is no need to use set-full-ratio for temporary adjustments.

If you have any questions or would like to learn more, feel free to join discussions about JuiceFS on GitHub and the JuiceFS community on Slack.

The architecture image shows GCS and others, so I suspect it does.

https://github.com/juicedata/juicefs#architecture

See also: JuiceFS: https://juicefs.com/

Adds a DBMS or key-value store for metadata, making the filesystem much faster (POSIX, small overwrites don't have to replace a full object in the GCS/S3 backend).

Almost certainly a better solution if you want to turn your object storage into a mountable filesystem, with the (big) caveat that you can't access the files directly in the bucket (they are not stored transparently).

JuiceFS can do the same thing as s3fs-fuse, but better. Because it supports robust data consistency and caching policies to improve performance.