We currently have a SVN repo structured like so



(it is more complicated than that, but this is sufficient to describe my issue)

I want to migrate this to git, but am facing a challenge. One developer highlighted that he often needs to make changes to libA, which may result in changes to libC and toolA (in fact around 4 different projects might need to change). Understandably he says that with SVN he just commits the library folder and all his changes get committed without having to go into each folder and do a separate commit.

With git, I would choose to have one repo per library, but he believes having to keep track of changes across projects like that would be error-prone. I do appreciate that if you had to make changes to 5 repos to fix a single bug, or add a new feature, it would be time consuming, and you might forget to add a change.

So as I see it I have some choices:

  • Group projects that frequently change together into a single git repo with subfolders. i.e. a library.git repo. For example

  • Refactor the projects to bring code with higher cohesion together into a single project

These are not my projects and the original author(s) have since left. To me the fact that seemingly unrelated projects frequently affect changes in each other isn't good design. I'd thus favour the latter choice, if it proves feasible.

I'd like to get some advice on the best strategy for this, which of my two suggestions is preferable, do I have other options, or should we just tell the developer to get over it?

  • 3
  • 1
    Key questions to ask: 1. Will I need to release libA, libC, libF, ToolA etc. separately? 2. Will I need to branch libA, libC, ToolsA separately? If you always branch them together and always release them together, usually means they will be happy in a single repo. Otherwise there's something worth discussing. Ahh and I used branch in the SVN-centralized sense here.
    – joshp
    Nov 15, 2015 at 22:43


Browse other questions tagged or ask your own question.