Major points for simplified organization. I’ve been at companies using many repos, that also don’t have a great way of organizing where those repos go. It’s annoying to find which repo has the code you need, but infinity bazillion times worse to figure out what fucking host the repo is on. Of course this can be mitigated by using some organization strategy or infrastructure for your many repos, but apparently that concept is lost on some people.
I’m still bitter.
I’m wondering what are the disadvantages of monolithic version control? Beside, potentially, the size of the repo (although only a problem for really large projects) are there other possible issues?
From experience it tends to lead to monolithic code by the ease of crossing module barriers when doing bug fixes in maintenance mode of the life cycle.
It can also lead to hard dependencies on customized libraries. Think when you are importing a third party library into your code and start applying patches to get going. I can even give you an open source example. I’m in the progress of porting Dart to OpenBSD. The project has a custom fork of:
Everything is pretty much hard wired. It takes tremendous effort to make it use system wide installed equivalents of their ‘third party’ dependencies. Not to mention that they embrace the third parties into their own build system essentially dropping any cross platform work that upstream might have done so far for other platforms.
When you have clear separation between the code you can easily change & your own product. By the nature of a clearly
defined API you will still have a working code base assuming that you adhere to the rules outlined between the projects. When that barrier is brought down - everything becomes ‘fair game’ especially when stuff is on fire.
I imagine it slows down most git operations, especially git pulls. As I understand it, developers are given laptops with the Facebook monorepo pre installed because it takes so long to clone.