2

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?

Daniel Williams
  • 8,912
  • 15
  • 68
  • 107

2 Answers2

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).

Christian Specht
  • 35,843
  • 15
  • 128
  • 182
  • nice! the subrepository seems like the way to go. if my core repo has 10 different projects, can I include as a subrepository ONLY the projects used by my client code? – Daniel Williams Dec 27 '11 at 22:50
  • 1
    Don't put more than one project into one repo. I just means that you build dependences between them that don't really exist. For example, to answer your question, if they're in the same repository you'd have to include all of them. Much better to have your 10 different core projects in 10 repos. It's cheap and easy, and there's no real reason not to. – Paul S Dec 29 '11 at 04:57
  • If possible, instead of subrepositories, collect dependencies from an artifactory and combine them in your build (using e.g. Maven or Ivy). Subrepositories have a whole bunch of conceptual problems and are seldom the best solution. – Laurens Holst Jan 02 '12 at 17:32
0

If you have developed custom code for clients which intereacts with your core product code, you should probably review it with every core update to ensure it does not get "out of synch with changes to our core code". Whether you are charging maintenance or separately for review and maintenance, this can be profitable. More important, it avoids failing code. Storing it by client makes doing this easier.

Patrick Moloney
  • 642
  • 5
  • 14