Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I want to know how to manage a big project with many components with version control management system.

In my current project there are 4 major parts.

  1. Web
  2. Server
  3. Admin console
  4. Platform.

The web and server part uses 2 libraries that I wrote. In total there are 5 git repositories and 1 mercurial repository. The project build script is in Platform repository. It automates the whole building process.

The problem is when I add a new feature that affects multiple components I have to create branch for each of the affected repo. Implement the feature. Merge it back. My gut feeling is "something is wrong".

So should I create a single repo and put all the components there? I think branching will be easier in that case. Or I just do what I am doing right now. In that case how do I solve this problem of creating branch on each repository?

share|improve this question

migrated from stackoverflow.com Jun 11 '13 at 18:27

This question came from our site for professional and enthusiast programmers.

    
Can you re-arrange your functionality to place as much as possible in shared libraries (Ruby gems, Python eggs, Java beans, etc), and then assemble the parts with the idea of "composing" each element out of the libraries? –  Narfanator Jun 11 '13 at 19:04
    
Think about when we add a new protocol support on Server component. We must also add proper interaction controls (buttons, fields etc) for this in web too. Thats the problem –  Shiplu Jun 11 '13 at 19:29
1  
That sounds like it's analogous to the "bridge" pattern; you might take inspiration from that. –  Narfanator Jun 11 '13 at 23:28
    
one repository to rule them all –  Steven A. Lowe Jun 28 '13 at 5:48

2 Answers 2

In the situation you describe, you are not getting any benefit from having multiple repositories, but you do have a cost: you can't roll back to an older version of a repository, and have any confidence that your system will continue to work. This is because your code is tightly coupled across repositories. As confidence in the ability to roll back is one of the main benefits of source control, this isn't the situation you want to be in.

The solution is to define your repository structure based on the coupling of the code within it: if project component A shares only stable interfaces with project component B, then they can be placed in separate repositories. Otherwise, they should be co-located in the same repository. A more granular repository layout will reflect a better factored system architecture.

share|improve this answer

If each of your repositories are stand-alone projects or libraries, then I'd say that there isn't anything inherently wrong with needing to create feature branches on each repo when adding new features that cross-cut across the projects. By being stand-alone, each one can be independently versioned and you can deprecate old APIs.

But in your particular case, it sounds like your repositories might not be grouping your code effectively. If changes to code in one repository requires changes to others (deprecation aside) then either your coupling is too tight or the repositories should be reorganized.

If all the repositories are really part of the same project (they can't stand alone) then maybe you should only have 1 repository. (Or maybe 2: the main project and one for generic/standardized functionality.)

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.