Monorepo? Why not just keep everything in one directory? Let's go 8.3. Everyone in same functional division? No way. Dependencies in your source are managed at a higher level. This whole thing is nonsense because the orgs can't figure it out. If you cannot figure out git or mercurial integration it's either institutional break down or...
Advantages of monolithic version control
71–80 of 144 posts
Re: Advantages of monolithic version control
#72Earlier quoted context omitted.
That sweet abuse of version control reminds me of the fabled JDSL from http://thedailywtf.com/articles/the-inner-json-effect
That can't be real... is it? No. No way.
It has to be made up. I am with you, that can no be real. There are trolls for everything.
Re: Advantages of monolithic version control
#73On the other end of the spectrum, a colleague of mine recently told me about when his previous company (big, 100k+ employees) were starting to adopt git, some people seriously considered having a separate repository per file ! "Because then you can just set up your project as using version X of file A and version Y of file B" It's good we now have (at least) Google, Facebook and Microsoft as examples of companies usi…
For a close enough real life example, and very often just one file (PKGBUILD), ArchLinux uses one (orphaned) branch per package:
https://git.archlinux.org/svntogit/packages.git/refs
https://git.archlinux.org/svntogit/community.git/refs
Orphaned branches allows you to have multiple independent trees in the same git repo, si it's basically a way to stuff many "repos" (as in history) in a single one (as in object storage).
Re: Advantages of monolithic version control
#74You can successfully use this approach only if you do not have external dependencies. If you use some library you have basically the same problem as multirepos. I worked in companies with monorepo and it work really well. Except all external dependencies were copied into monorepo, outdated and with unpatched security problems because no one ever updated them unless there was some functionality missing. Also there were some internal libraries for logging etc. which were worse than publicly available alternatives but it was easier to maintain them then use something standard.
Re: Advantages of monolithic version control
#75On the other end of the spectrum, a colleague of mine recently told me about when his previous company (big, 100k+ employees) were starting to adopt git, some people seriously considered having a separate repository per file ! "Because then you can just set up your project as using version X of file A and version Y of file B" It's good we now have (at least) Google, Facebook and Microsoft as examples of companies usi…
For a close enough real life example, and very often just one file (PKGBUILD), ArchLinux uses one (orphaned) branch per package : https://git.archlinux.org/svntogit/packages.git/refs https://git.archlinux.org/svntogit/community.git/refs Orphaned branches allows you to have multiple independent trees in the same git repo, si it's basically a way to stuff many "repos" (as in history) in a single one (as in object stora…
That seems very weird. Do you happen to know the reasoning behind it?
Re: Advantages of monolithic version control
#76I initially found the idea of monolithic repositories hard to digest. But now I think it's a good idea for some of the reasons outlined in the article. Namely, it's very easy to depend on other code that the organization has created. In the open source world, I have found some Unix distros use the same model. I know it's not as extreme, but the principle is quite similar. For example, in Nixpkgs all package definitio…
I initially found the idea of monolithic repositories hard to digest. But now I think it's a good idea for some of the reasons outlined in the article. Namely, it's very easy to depend on other code that the organization has created. I remember the days when monorepo was the norm, and distributed version control was the weird, kooky idea. Mainstream programmers had knee-jerk notions that all managed environments were…
>For game development, monorepo is simpler. If one is using git, one needs to use some other software to turn the part of your repository for media into a monorepo, otherwise the asset files become a burden. (gitannex, for example)
I think this has more to do with how git handles diffs more than monorepo vs distribution. As you said, git lfs solves the issue with centralization but that's not the same as a monorepo. You can still split all your libraries out in such a system without issue.
Re: Advantages of monolithic version control
#77> With a monorepo, projects can be organized and grouped together in whatever way you find to be most logically consistent, and not just because your version control system forces you to organize things in a particular way. Using a single repo also reduces overhead from managing dependencies. This is the major thing I miss about Subversion, and the fact that in Subversion a subdirectory in a repository can be checked…
You can get all this functionality with git, gitlab and looking through the consolidated activity page, no?
Re: Advantages of monolithic version control
#78I personally find multi-repo thinking leads to better architecture. Cross project change history seems nice but if the projects are that coupled in the first place, why are they difference solutions to begin with? If you're building decoupled code you shouldn't need cross project changes.
That said, I understand the worth of getting things done at the expense of rigor so I chalk this topic of discussion up to personal taste. It's akin to the dynamic vs static typing debate.
Re: Advantages of monolithic version control
#79Earlier quoted context omitted.
The class of problems I’m talking about are integration issues. Unit tests look good but when you put the pieces together... When the tests that matter cross version control boundaries you pay for it. Whether the costs outweigh the benefits is something you have to think about.
What does your test coverage look like? Perhaps you're missing something there that would have caught that bug? Testing is, of course, no silver bullet. Tests are written by humans, and humans make mistakes—and it's pretty difficult to achieve 100% test coverage in a production system. The goal of testing is to have confidence in the code you've written. Tests often don't need to cross version control boundaries. You…
>Tests often don't need to cross version control boundaries. You can use mock data—like would be produced by the library—on the consumer side, because you can delegate responsibility for testing of that library to the library repository itself.
I take it as a rule of thumb that a more realistic test is better than a less realistic test.
I can't think of any reason why you would want to mock anything if using the real thing is cheap and easy, building mocks is expensive, and testing against the real thing will increase the chances of detecting real bugs.
I also prefer it when my tests detect bugs in other libraries which my code depends upon because as far as users are concerned, bugs in libraries my code depends upon are bugs in my code.
I have in the past written a bunch of functional tests which check out / pull and build code from other repos to run with my code.
Re: Advantages of monolithic version control
#80Earlier quoted context omitted.
Any changes you need to make to internal libraries you install via package manager would need to be made to those separate repositories that house the libraries, and then those changes would have a release made (generally this is done through a git tag, and using semantic versioning). Once you update the version, your package manager will allow you to install that update to the other places you're using it, so all yo…
And how do you test if a change in one of these repos fixes the problem you’re seeing? This is what we’re failing at with our multirepo. That and resectioning code to split or combine responsibilities in different ways. Something a monorepo makes trivial.
Some (most?) package managers allow you to install to your local cache for local testing. Nuget and Maven allow this at least.