HN Explorer

Ask HN: Single repo vs. repo for each service?

2 points by BhavdeepSethi ↗ HN
Recently I’ve been working with having the entire codebase in a single repo way and it’s not really been a good experience. Every time someone modifies code in a separate module, I have to recompile/generate sources to fix the compilation errors. Not to mention compiling takes a lot of time as well. Some of the points in favor of the single codebase approach I’ve heard is that you don’t have to worry about versioning. Since everyone has to pull in the same changes, everyone has access to the same thrift sources as well.

I’m mostly accustomed to having separate repository for each service. Personally, I think it makes it more manageable. It goes hand in hand with the SOA approach. A bad commit in another service doesn’t affect you.

Yet, I’ve seen the single codebase method in bunch of orgs. I believe Google does this as well? I'm curious to know which one is more common. What are the pros/cons that have factored into choosing one over another?

3 comments

[ 3.8 ms ] story [ 22.2 ms ] thread
tdy721
I like to make lots of repos. You can get a combination of both going with git when you merge repos together. They don't have to share history. You can setup remotes that are just paths on your system and make a single repo that contains branches for each service. You'll end up cloning a single repo a bunch of times, and fussing with branches instead of repos.
Ameo
Ugh - having only worked on personal projects with github up to this point, the thought of complicated series of repos just to work on multiple aspects of a project sounds like a huge hassle.
w4tson
Devs should never be checking in code that results in a compilation error. Regardless of whether something needs generating.

Also there’s a difference between an entire companies code in one VCS and a product with many modules.

I’ve had experience with the latter and can tell you some of the pro’s:

1. A single version for your product. This helps communications with QA, clients and managers. And communication is the game we are in whether we like it or not

2. Reduced friction in developing features that cut across modules. Lets say I need to add a column to a database and then expose in the Ui. update the sql, added the field in a webservice, make the necessary adjustments in the UI, write the tests all on the same commit.

3. Increased collaboration. Quite often invisible lines are drawn on development teams where devs are feel they are unable to modify a module because they didn’t write it, they don’t understand it or they just feel that its not a part of their job. With everything in one repo this reduces the barrier to entry

Its not a free lunch though. Like you mention build times go up For one.

I’m a jvm dev and I find gradle extremely useful in this regard. Features like Muti project builds and concurrent builds are invaluable