monorepo

There are a number of potential advantages to a monorepo over individual repositories:{{cite journal |last1=Potvin |first1=Rachel |last2=Levenberg |first2=Josh |date=July 2016 |title=Why Google Stores Billions of Lines of Code in a Single Repository |url=https://cacm.acm.org/magazines/2016/7/204032-why-google-stores-billions-of-lines-of-code-in-a-single-repository/fulltext |accessdate=20 July 2018 |journal=Communications of the ACM |doi=10.1145/2854146 |volume=59 |issue=7 |pages=78-87|doi-access=free }}{{cite book |last1=Brousse |first1=Nicolas |title=Proceedings of the Conference Companion of the 3rd International Conference on Art, Science, and Engineering of Programming |chapter=The issue of monorepo and polyrepo in large enterprises|chapter-url=https://dl.acm.org/citation.cfm?id=3328435 |year=2019 |pages=1–4 |doi=10.1145/3328433.3328435 |isbn=9781450362573 |s2cid=201670751 |accessdate=7 September 2019}}

; Ease of code reuse

: Similar functionality or communication protocols can be abstracted into shared libraries and directly included by projects, without the need of a dependency package manager.

; Simplified dependency management

: In a multiple repository environment where multiple projects depend on a third-party dependency, that dependency might be downloaded or built multiple times. In a monorepo the build can be easily optimized, as referenced dependencies all exist in the same codebase.

; Atomic commits

: When projects that work together are contained in separate repositories, releases need to sync which versions of one project work with the other. And in large enough projects, managing compatible versions between dependencies can become dependency hell.{{cite AV media

| people = Aimee Lucido

| date = 7 April 2017

| title = Uber Technology Day: Monorepo to Multirepo and Back Again

| url = https://www.youtube.com/watch?v=lV8-1S28ycM

| access-date = 24 July 2018

}} In a monorepo this problem can be negated, since developers may change multiple projects atomically.{{cite book |last1=Santacroce |first1=Ferdinando |last2=Olsson |first2=Aske |last3=Voss |first3=Rasmus |last4=Narebski |first4=Jakub |title=Git: Mastering Version Control |date=2016 |publisher=Packt Publishing Ltd |isbn=9781787122796 |page=756 |url=https://books.google.com/books?id=_5bcDgAAQBAJ&q=monorepo&pg=PA756 |language=en}}

; Large-scale code refactoring

: Since developers have access to the entire project, refactors can ensure that every piece of the project continues to function after a refactor.

; Collaboration across teams

: In a monorepo that uses source dependencies (dependencies that are compiled from source), teams can improve projects being worked on by other teams. This leads to flexible code ownership.

; Loss of version information

: Although not required, some monorepo builds use one version number across all projects in the repository. This leads to a loss of per-project semantic versioning.

; Lack of per-project access control

: With split repositories, access to a repository can be granted based upon need. A monorepo allows read access to all software in the project, possibly presenting new security issues.{{cite web|last1=点融黑帮|date=16 August 2017|title=浅谈monorepo|trans-title=Talking about monorepo|url=http://www.sohu.com/a/165037119_575744|website=Sohu|language=Chinese|accessdate=20 July 2018}} Note that there are versioning systems in which this limitation is not an issue. For example, when Subversion is used, it's possible to download any part of the repo (even a single directory), and path-based authorization can be used to restrict access to certain parts of a repository.

; More storage needed by default

: With split repositories, you fetch only the project you are interested in by default. With a monorepo, you check out all projects by default. This can take up a significant amount of storage space. While some versioning systems have a mechanism to do a partial checkout,[https://git-scm.com/docs/partial-clone git partial clone][http://svnbook.red-bean.com/en/1.8/svn.advanced.sparsedirs.html Svn Book: Sparse Directories][https://www.perforce.com/manuals/v17.1/p4v/dvcs.clone.html Perforce: Clone] doing so defeats some of the advantages of a monorepo.

Companies with large projects have come across hurdles with monorepos, specifically concerning build tools and version control systems.{{cite web |last1=Goode |first1=Durham |author2=Rain |date=7 January 2014 |title=Scaling Mercurial at Facebook – Facebook Code |url=https://code.fb.com/core-data/scaling-mercurial-at-facebook/ |accessdate=24 July 2018 |website=fb code |language=en-US}} Google's monorepo, speculated to be the largest in the world, meets the classification of an ultra-large-scale system and must handle tens of thousands of contributions every day in a repository over 80 terabytes in size.{{cite magazine |last1=Metz |first1=Cade |title=Google Is 2 Billion Lines of Code—And It's All in One Place |url=https://www.wired.com/2015/09/google-2-billion-lines-codeand-one-place/ |magazine=WIRED |accessdate=20 July 2018|date=16 September 2015}}

{{See also|Version control}}

Companies using or switching to existing version control software found that software could not efficiently handle the amount of data required for a large monorepo. Facebook and Microsoft chose to contribute to or fork existing version control software Mercurial and Git respectively, while Google eventually created their own version control system.

For more than ten years, Google had relied on Perforce hosted on a single machine. In 2005 Google's build servers could get locked up to 10 minutes at a time. Google improved this to 30 seconds–1 minute in 2010.{{cite web |last1=Bloch |first1=Dan |url=https://storage.googleapis.com/pub-tools-public-publication-data/pdf/39983.pdf |accessdate=23 July 2018|title=Still All on One Server: Perforce at Scale}} Due to scaling issues, Google eventually developed its own in-house distributed version control system dubbed Piper.

Facebook ran into performance issues with the version control system Mercurial and made upstream contributions to the client,{{cite web |last1=Claburn |first1=Thomas |title=Facebook is writing a Mercurial server in Rust. This is not a drill |url=https://www.theregister.co.uk/2016/10/18/facebook_mercurial_devs_forget_git/ |website=The Register |accessdate=20 July 2018 |language=en}} and in January 2014 made it faster than a competing solution in Git.{{cite web |last1=Blewitt |first1=Alex |title=Facebook makes Mercurial faster than Git |url=https://www.infoq.com/news/2014/01/facebook-scaling-hg |website=InfoQ |accessdate=24 July 2018|date=9 Jan 2014}}

In May 2017 Microsoft announced that virtually all of its Windows engineers use a Git monorepo.{{cite web |last1=Lardinois |first1=Frederic |date=24 March 2017 |title=Microsoft now uses Git and GVFS to develop Windows |url=https://techcrunch.com/2017/05/24/microsoft-now-uses-git-and-gvfs-to-develop-windows/ |accessdate=20 July 2018 |website=TechCrunch |language=en-US}} In the transition, Microsoft made substantial upstream contributions to the Git client to remove unnecessary file access and improve handling of large files with Virtual File System for Git.{{cite web |last1=Bright |first1=Peter |title=Windows switch to Git almost complete: 8,500 commits and 1,760 builds each day |url=https://arstechnica.com/information-technology/2017/05/90-of-windows-devs-now-using-git-creating-1760-windows-builds-per-day/ |website=Ars Technica |date=24 May 2017 |accessdate=20 July 2018 |language=en-us}}

{{See also|Build automation}}

Few build tools work well in a monorepo,{{cite AV media

| people = Dorothy Ordogh

| date = 5 April 2018

| title = Pants and Monorepos

| url = https://www.youtube.com/watch?v=IL6LBWNi3fE

| access-date = 24 July 2018

}} and flows where builds and continuous integration testing of the entire repository are performed upon check-in will cause performance problems.{{cite web |last1=Farina |first1=Matt |title=Dangers of Monorepo Projects - DZone DevOps |url=https://dzone.com/articles/dangers-of-monorepo-projects |website=DZone |accessdate=20 July 2018 |language=en}} A build system that processes dependencies as a directed graph (such as Buck, Bazel, Please, or Pants) solves this by compartmentalizing each build or test to the active area of development.{{cite web |last1=Hammant |first1=Paul |last2=Smith |first2=Steve |title=Trunk Based Development |url=https://trunkbaseddevelopment.com/monorepos/ |website=trunkbaseddevelopment |accessdate=24 July 2018}}

Twitter began development of Pants in 2011, as both Facebook's Buck and Google's Bazel were closed-source at the time.{{cite web |last1=Mohilo |first1=Dominik |title=8 Build-Tools im Vergleich: Ant – Buildr – Maven – Bazel – Buck – Gradle – Pants – sbt - JAXenter|trans-title=8 build tools compared: Ant - Buildr - Maven - Bazel - Buck - Gradle - Pants - sbt|url=https://jaxenter.de/8-build-tools-im-vergleich-ant-buildr-maven-bazel-buck-gradle-pants-sbt-41627 |website=JAXenter |accessdate=20 July 2018 |language=de-DE |date=10 June 2016}} Twitter open-sourced Pants in 2012 under the Apache 2.0 License.{{cite web |last1=Moore |first1=Madison |title=GitLab releases security fixes, Pants 1.0, and Sauce Labs integration for JIRA—SD Times news digest: May 3, 2016 - SD Times |url=https://sdtimes.com/apache/gitlab-releases-security-fixes-pants-1-0-sauce-labs-integration-jira-sd-times-news-digest-may-3-2016/ |website=SD Times |accessdate=20 July 2018 |date=3 May 2016}}

Please is a Go-based build system; it was developed in 2016 by Thought Machine, whose developers were both inspired by Google's Bazel and dissatisfied with Facebook's Buck.{{cite web |last=Ebden |first=Peter |date=December 2017 |title=Please - the Thought Machine Build System |url=https://www.thoughtmachine.net/blog/please-the-thought-machine-build-system/ |department=Blog |website=Thought Machine |archive-url=https://web.archive.org/web/20191228224526if_/https://www.thoughtmachine.net/blog/please-the-thought-machine-build-system/ |archive-date=2019-12-28}}

{{Reflist|30em}}

{{Version control software}}

Category:Version control

Category:Software development process