Imagine you are working on a project for a huge company, a multinational, perhaps a unicorn. At your previous job you worked with version control systems like Git, so you arrive and do the typical git clone to fetch the repository. To your amazement, you discover that the repository takes up a whopping 270 GB. It is enormous, but you decide to wait while reviewing the requirements your project manager has sent you.
After the wait, you think "I'll create a new branch to work on so I don't bother anyone; when I'm done I'll merge it into production and that's it." You do a git checkout and — surprise! You have to wait a couple of hours for it to complete. "This can't be right," you think. Panic sets in and you decide to check the status of the repository (to see if you did something wrong). git status and — more waiting, another 10 minutes! This is madness...
Now imagine this scenario is not hypothetical, but real. That the multinational is Microsoft and the repository is the Microsoft Windows source code. Since this is a truly unsustainable problem for developers (Microsoft cannot have dozens of people sitting around waiting for a simple git status), their engineers have gotten to work and have created an improved version of Git which they have called GVFS, standing for Git Virtual File System (not to be confused with Gnome Virtual File System).
What GVFS does is virtualize the repository's file system; this way the developer gets the impression that all files are present when in reality they are only downloaded the first time they are opened. In general (at least in my experience) when adding a new feature or fixing a bug, you tend to touch the same files over and over again. It is very rare to have to edit all the files in a project, so this represents an incredible improvement when working with repositories containing thousands of files (Microsoft Windows has around 3.5 million lines of code).
Furthermore, in repositories of this size, developers do not need to compile the entire project. Instead they download small portions of the final build, and only compile those parts that directly affect their development. According to Microsoft, an average developer downloads and uses between 50,000 and 100,000 lines of the nearly 3 million that make up the Microsoft Windows repository.
With this system, Microsoft has managed to make cloning a repository take only a few minutes, a checkout require 30 seconds instead of 2 or 3 hours, or a status take 4 or 5 seconds instead of 10 minutes. Although these times may still seem quite high, it should be kept in mind that these are cold times; that is, when everything has to be done from scratch on a new machine. If we already have the repository and are switching branches and so on, these times would be the normal ones that "the rest of us mortals" experience with our own repositories.
Best of all? Microsoft has open-sourced this client. They have also made changes to Git to allow this new type of GVFS repository to be used, and have implemented a communication protocol that is documented here.
For now it seems to only work on Windows 10 as it is a Git client for Windows, although quite a few people are asking for it to be made available for Linux and macOS as well. Hopefully, even if not officially, the power of the open-source community will make it happen. Because I don't manage repositories that large, but if I can shave a couple of seconds off my daily Git work, so much the better.