As a user I would like Git Virtual File System to be a Supported Platform

Update on July 2019

Hi everyone,

Thanks for your feedback. I wanted to let you know that Bitbucket GVFS app is still experimental. We reviewed the feedback on this suggestion and recent GVFS(VFS) updates and decided to keep the app as experimental because:

• GVFS is still only supported for Windows clients. Mac one is still under development
• Lack of API documentation - new version of GVFS was released recently and it broke the integration in Bitbucket but, there is no change in API documentation
• There's work going on in Git itself to support partial clones and promisor remotes--which would largely obsolete the functionality provided by GVFS

We are following the developments in the git community and from Microsoft. If our view on this changes in future then, we will post an update. Please vote/watch to follow the updates. We are keeping this suggestion open to get feedback. 

Cheers,
Imran Khan
Product Manager - Bitbucket Server and Data Center

Update on October 2017

The Atlassian Marketplace provides an experimental add-on for Bitbucket Server and Data Center that adds the server-side support needed to serve GVFS-enabled Git clients. It can be installed on any supported server platform and once installed Bitbucket will handle GVFS protocol requests for any repository without any additional setup, from properly configured Git clients.

For more information about setting up GVFS on the client side, please see the blog post and linked resources from Microsoft. As at October 2017, only Windows client support was available. Sourcetree 2.0 and above for Windows is also GVFS aware when used with a GVFS enabled client.

Like GVFS itself, the experimental add-on is relatively new, and unsupported, which is why this suggestion is still open. It is an experimental technology preview not intended for production use, though being a distinct code path it is unlikely to introduce side effects for non-GVFS users on a production instance. If you work on large repositories, we’d love for you to take it for a spin and send us your feedback.

Problem Definition

Working with monolithic Git repositories can be negatively affected by slow performance, especially long clone times and wasteful operations to determine what's changed in a local repository.

Suggested Solution

Support GVFS protocol. 

Why this is important

As to the reasons we need a monolithic repo, well our reasons are the same as those that motivated Microsoft to create the Git Virtual File System in the first place. The reasons include:
1) We have a large number of source files (close to 1 million)
2) Git and Bitbucket do not support large repositories well, or large binary files for that matter. We have both.
3) In almost all cases, changes per a release span a significant percentage of our projects and these changes are all related. Here's an applicable quote from a Microsoft article (https://blogs.msdn.microsoft.com/bharry/2017/02/03/scaling-git-and-some-back-story/) that describes our situation nicely:

"Since all of Windows – the kernel, the libraries, the applications – are released together, they’re also versioned together, in a large “monorepo“. When planning the Windows move to Git, we looked at breaking the codebase down into many smaller repositories and layering them together with Git submodules or a system like Android’s repo. But sometimes monorepos are just the easiest way to collaborate."

As is right now, we were forced to break up our source into around 30 repositories. And though doing that was fairly straightforward, producing releases now is a real pain since we often have related changes in all 30 repositories. Sometimes, in big highly related code bases, it really is better to treat the codebase as a whole.