> Is it really a single big repo for the whole organization?

Yes. It's incredible. It enables organization-wide refactoring. It facilitates code sharing. It provides easy access to examples of how code should be used.

> What happens if you want to deploy your code on servers?

You don't deploy source, you deploy packages. At Google we use bazel/blaze (http://bazel.io/). The build rules specify dependencies and visibility allowing for logical separation rather than the incidental separation that comes with chopping up your repository.

Having worked with a monorepo I never want to go back.

> It enables organization-wide refactoring.

How do you mean? If I refactor the backend, for example, an iOS dev still needs to come in and refactor the iOS app, so the refactoring still happens independently.

> It facilitates code sharing.

That's handy if many or your projects are in the same language, true. That generally didn't hold for the projects I've worked on.

> It provides easy access to examples of how code should be used.

True, but that's mostly the same as having a GitLab instance (or similar) installed.

> You don't deploy source, you deploy packages.

Sounds like I just have different needs, in my area of development (Python server backends) the source is the package.

> How do you mean? ... so the refactoring still happens independently.

Not all refactors modify APIs, and even some that do can be programmatically applied. Suppose you've deprecated method Foo(..) and have a replacement Bar(..). With access to all the source, you can change things globally, it's great. One funny programming 'mistake' that creeps into code that's been around a while is dodgy looking ternary operators:

    return (foo ? true : false)
    return (foo ? false : true)

With a few minute's work, one engineer can metamorphose all of these into:

    return foo;
    return !foo;

> That's handy if many or your projects are in the same language, true.

My day to day work is almost exclusively C++. Thousands of other engineers are in the same boat as me. We all benefit from a fabulous tools team.

Are you really using a checkout on a production server to install and configure your software?

This feels like a "Doctor, doctor - it hurts when I stick a spoon in my eye" moment - "Don't do that!"

Build tools and build servers exist for a reason.

Subversion has "svn export" if you insist on working that way. git can git clone repos --depth 1; rm -rf repos/.git if you really, really must.

And what you are calling polluted history, they are calling efficient collaboration.

If there exists appropriate tooling (e.g. for filtering commit logs based on what touched the code belonging to a single project / what touched the code belonging to a single project and its transitive dependencies) then I dare say a huge monorepo history over many projects and libraries isn't polluted history, it is remarkably rich and useful history.

In big places with solid engineering teams and a long-term investment in infrastructure it seems achievable to build the tools to do this properly. (famously: google, which isn't a very fair example).

I think many people's default reaction to monorepos -- fear, loathing and disbelief, say -- is based upon working with open source tools / related cloud services / distributed workflows - that scale poorly when dealing with large repositories, at least with default configuration and without a lot of mucking about.

That said, this default reaction is arguably a healthy reaction if the reality is that most teams / organisations do not have the resources to invest in setting up tooling / infrastructure beyond what they can get for free / rent for a few hundred dollars a month.

> Build tools and build servers exist for a reason.

What's the build server going to do? Copy the Python code from the repo to the other server? It doesn't seem like setting up a build server just to do "git checkout; rm .git" is worth the effort.

I mostly work with java, so the build server is doing a clean compilation, to ensure the code word outside my dev environment. Pulling in known versions of dependencies, some packaging, unit and integration tests etc. Mostly using Maven.

Whilst some of that is somewhat specific to java, I'd still want a build server to ensure I hadn't managed to pollute my dev environment with and undeclared dependency before I pushed my code to production. And I'd still want to run at least some integration tests, even for the simplest project.

And I really REALLY don't want my internet facing servers to be able to reach into my internal network, which means a checkout simply isn't going to work anyway.

Lastly I don't want my code on those servers either. You can set up .htaccess or equivalent to prevent access to .svn or .git (or dotfiles in general..) but those files really shouldn't have been there in the first place.

> I'd still want a build server to ensure I hadn't managed to pollute my dev environment with and undeclared dependency before I pushed my code to production.

In my case, the production server is the build server. You can't have dev dependencies there, because you don't develop there.

> And I'd still want to run at least some integration tests, even for the simplest project.

Integration tests run on the dev or CI server, in my case.

> And I really REALLY don't want my internet facing servers to be able to reach into my internal network, which means a checkout simply isn't going to work anyway.

The code servers aren't in the internal network, in my case. They're already internet-facing, since I need to pull from them.

> Lastly I don't want my code on those servers either. You can set up .htaccess or equivalent to prevent access to .svn or .git (or dotfiles in general..) but those files really shouldn't have been there in the first place.

In my case, if my code isn't on the server, the server doesn't run. There's no need to set up .htaccess, since the HTTP server doesn't serve anything off the filesystem.

>> I'd still want a build server to ensure I hadn't managed to pollute my dev environment with and undeclared dependency before I pushed my code to production. >In my case, the production server is the build server. You can't have dev dependencies there, because you don't develop there.

The problem is not that dev dependencies exist, the problem is that they might be undeclared or unrecorded. I have imagemagic on my dev machine, but if it isn't installed as part of the server setup script, then it won't be on the production server. The tests might run fine on a dev server that happens to have imagemagic on it, but fail in production.

>Integration tests run on the dev

If you run your integration tests in your dev environment, you might not catch some on the fly configuration changes or utility installations - undeclared dependencies.

I'm using "dev environment" and "dev server" distinctly. The dev environment is whatever I have on my computer, the dev server is a server that mirrors production. If there's a dependency on your dev environment that isn't on production, you'll catch it when you deploy to one of the dev servers. Same with the integration tests.

Suppose you've invested in a build server anyway, for CI.

Then you can just add/extend a job to create a release package, and deploy it.

Doesn't take that much effort, and lets you avoid infecting your production boxes with dev infrastructure/scaffolding, as `NickNameNick` suggests.

What sort of def scaffolding do you mean? The benefits of just pulling the repo are that you can use ansible-pull to automatically update the servers whenever new code is merged to master, which would be more complicated if you had the CI server doing the pushing.

> What sort of def scaffolding do you mean?

version control software, to start with. perhaps more.

i guess my viewpoint is coloured as the last thing i was working on was deployed to client desktop machines. there was absolutely no way we were going to be pushing to those with version control.

if you are deploying to a server you own, i guess in principle you can do whatever you want. one of my colleagues rigged a build to create a debian package for the server-side version of the code we worked on. that took a bit of mucking about to get going but was very nice when it was set up.

Building a deb is also an option, I generally don't prefer it because just pulling is easier to set up, and debs don't have that many advantages when you're dealing with interpreted server code.

Set up a virtualenv with defined versions of all dependencies, on install the python code there. And tar up the virtualenv.

Or create a .deb or .rpm package out of the python code.

In a non-trivial setup, just doing a 'git checkout' isn't enough for a deployment.

I'll just point out that your assumption that I'm only doing a "git checkout" is completely unwarranted.

Given that in the comment to which that was a reply, you opined that 'It doesn't seem like setting up a build server just to do "git checkout; rm .git" is worth the effort.', it's not completely unwarranted.

The part that the build server can handle is the "git checkout" part, maybe create a virtualenv with the dependencies. In that case, doing a "git checkout" is enough for deployment, because you're already assuming that the rest of the deployment happens elsewhere.

If you're working with Python, you can create builds of individual modules via zip archives. This lets you create a versionable, signable build artifact which can be easily deployed almost everywhere. They can even include static versions of you dependencies, making the deploy less reliant on what is installed on the target server.

A great tool for this is pex: https://github.com/pantsbuild/pex

It is for the who,e organization. No you don't have to checkout the whole repo, you can check out a filtered portion, usually a sub folder or two. You can also do a shallow checkout without history.

There are compelling benefits to pulling from repo once, packaging, whether that means zipping, just putting code in a folder or putting it into a docker image, then promoting that "build" everywhere. Including running your integration, acceptance, and manual tests on it.

As soon as we started doing that we found benefits even for our Ruby code that is also a pretty much copy and paste deploy. It turns out there were differences in how UTF8 was ha fled by default on Ubuntu vs OSX. We ran into the same thing a few years back with some system clock behavior that behaved differently on our dev macs and Linux. All works the same in our docker images.

Of course we do see stronger benefits with our compiled code, and if all of your code is interpreted the. Maybe it is t worth it in your case, but I have certainly benefitted from it in my small shop of less than 10 devs so it isn't just something for huge companies.