4 ms·
3) Google is committed to a monorepo to the point migrating away from it would be unpractical. Truth is, ending up with a monorepo is _really easy_. It usually
by LaGrange 8y ago
3) Google is committed to a monorepo to the point migrating away from it would be unpractical.
Truth is, ending up with a monorepo is _really easy_. It usually starts with something that doesn't even _feel_ like more than one project: backend code, frontend templates and some celery/whatever tasks, maybe some minor utility CLI tools. And this happens at the stage nobody wants to even _think_ about more than one git repository.
Once those are big enough, it's likely too late.
But hey, you can always claim _you wanted it that way_. My cats always look good while pulling that one.
- banachtarski 8y agoI've worked with both monorepo orgs, and polyrepo orgs. I think if you have only used git as your VCS and not something like perforce, you're likely to get the wrong idea of how it works. Both CAN work, but for internal organizations with a reasonably sized team, I've come to realize that a mono repo is better. You attain "separation" by establishing different views of the code/data and at scale, the mental model of what's happening is much simpler.
- LaGrange 8y ago> I think if you have only used git as your VCS and not something like perforce I think if you worked with Perforce, you're likely to get the wrong idea that people who dislike monorepos didn't work with Perforce. But the reality is that anyone who worked in this industry long enough did at some point end up traumatised by it, thanks. > the mental model of what's happening is much simpler. How does introducing the concept of "views" to the VCS model make anything simpler?