Problem validation for native support for large binary files (viable maturity)
Problem Statement
LFS is a pain. Large files "just work" in CVS and Perforce. I want large files to just work in Git.
Significant tooling investments and different workflows are common to centralised version control systems, which means this isn't simply a new Git flag.
Reach
The frustration of working with large files is primarily felt by developers and other collaborators in the development of projects that require binary assets, the most prominent being games development. There is often desire from these teams to move to Git, and administrators of CVS and Perforce instances also frequently desire to consolidate to Git where possible.
Improving support for large repositories will also likely have trickle down impact for moderately sized projects. I have excluded this from the reach estimate.
1.5 = Small reach (~5% to ~25%)
Impact
There is currently no way to use Git for these types of projects. This means many companies using Git also maintain secondary systems like Perforce and CVS. For these customers, the impact of GitLab natively supporting large files would be massive because it would allow them to consolidate workflows and tools across the whole organization.
3.0 = Massive impact
Confidence
Customer conversations with large and strategic accounts of GitLab, reveal many of them use GitLab and another VCS, and have the desire to consolidate.
100% = High confidence
Effort
This is a complex feature which includes contributing and testing improvements to the Git client, improvements to the Git server and Gitaly to scale GitLab's server side support for these kinds of repositories, and the UX changes required to educate and deploy this feature to a large organization.
In order to ship an Minimal implementation for testing:
- Design/Research effort: Low. We have highly collaborative customers that are eager to help us test.
- Product effort: High. We will need to work closely with our pilot customers to understand the challenges of moving projects from P4 and CVS to Git, beyond simply the migration of tools. Improvements to file locking, APIs and other related features may be critical to the adoption of Git for large files even though they are technically unrelated to Git scalability.
- Engineering effort: High. Scaling Git from a few gigabytes to hundreds of gigabytes is hard and we do not yet have reference repositories to test with. High unknowns are associated with this project.
For the sake of t-shirt sizing, I'll estimate 6 person-months to get to the MVC.
Score
(1.5 Reach * 3.0 Impact * 100%) / 6.0 Effort = 1.5