Question

I work at a company that does a good deal of custom development for a wide variety of clients. Some projects are unique, but many of them also use a common set of code that we have developed over the years. This pattern has worked well for a long time. But we are currently in the process of moving from SVN to Mercurial (hg), and so I’m pondering how best to set up the different repositories.

Right now we have one repo for our internal work. These projects range from basic utilities such as logging, to custom apps for internal use. And it also has a good deal of old code that is not actively updated, but kept around in case some old legacy client code needs to be modified.

For each client we make a separate repo and put all of their code in the dedicated repo.
The nice thing about this structure is that if you want to work on a client’s code, you just get everything from their repo, plus the “core” internal code, and you have everything you need. One downside is that the client code can become stale, and even out of synch with changes to our core code.

But I would like to hear what other people do as well. Does it make sense to have many client-specific repositories and one rather large internal one? Some client’s code base is huge, while others’ are very small. Does it make sense to have a repo for each?

Also – we put ALL client artifacts into each client repository. This includes not only source code, but also specs, contracts, signed PDFs, Excel, Visio, Word, and other such documents. This seems wasteful to me, and I’m pondering separating out the artifacts from the true code. How do others handle such things?

Answer 1

You could do the following:

• put the core code in one central repository
• put the client code in client-specific repositories
• do not put copies of the core code directly in the client repositories, instead include the core code repository as a subrepository

This gives you the benefit that you can still just pull the client repository and get the client’s stuff and the core code.
Plus, the subrepository automatically points to a certain revision of the core code repository, and you have to do an explicit update if you want a newer version. So if the core code repository is updated in the meantime, the subrepository in the client repository does not automatically get these changes (which might break your client code).