7

We are currently porting our huge svn repo to git and we are thinking to export subdirectories of repository, each one containing source code of independent binaries, documentation or robot tests, into separate git projects.

One of those is a library that is currently being developed and all of the binaries depend on it.

All of those directories/binaries/docs etc are currently developed.

Should we separate all of those into separate git repos or add submodules or keep it as it is one huge repo?

Catalog structure:

/trunk/src/
    binary1/
    binary2/
    binary3/
    binary4/
    binary5/
    library/
    TA_tests/
    docs/
    scripts/
Patryk
  • 1,269
  • 3
  • 13
  • 14
  • 1
    The answer I would give to this question is very similar to the accepted answer in gnat's link, so I'm leaning towards duplicate. – Ixrec Jan 21 '15 at 22:54

3 Answers3

2

For my work we use separate repos and maintain versions for each module.

Pros

  • Not all of the modules are required for each project so we are able to easily keep the size of each project down
  • Commit history is specific to the module
  • It is easy to use specific versions or branches of the module when needed.

Cons

  • We have to use a package manager to maintain dependencies
  • Dependencies can have conflicts e.g. one module requres v0.1.3 of a module called utilities and another module requires v2.0.2 of utilities

Other Thoughts

If the project you are on is a single project with lots of parts it is less important to keep things separate. It might still be easier if each module were separate. But if you have lots of small or medium projects that use various modules then it is very useful to have separate repos.

Community
  • 1
payne8
  • 176
  • 5
  • I'm sorry, but I think that "using a package manager to maintain dependencies" is never a 'con'. Maven is an example tool which manages dependencies well. So calling dependency management a con is like saying that using maven is a con, and that's not true. (maven does more than dep mgmt, but dep mgmt is a _huge_ part of it). Also, your second con bullet point is wrong. That's not a conflict at all. If my project uses rails version 2, and yours uses rails version 3, then how is that a problem? In the real world, different versions are always used. Any dep mgmt system can handle that fine. – Alexander Bird Apr 09 '15 at 16:28
1

Keeping only one big repository is an error for me because your commit timeline will be burdened by many commits that have nothing to do with you project and you will be blocked often at push-time for no reason.

I think you have three choices:

  • git submodules: if you want a certain degree of separation between your librairy and your repository. It can be justified if you want to slightly decouple them. It offers a managed way to deal with your dependency but does give you a fix point for your updates.
  • Having a dependendy manager that fix the version you want to use (as Composer does). The benefit here is to be able to control the version you use and to not have bad surprise when you update your repository. But you have to remember to update it when it changes.
  • git subtree: that is the most coupled solution, if you want to a transparent way to deal with this dependency. The benefit here is to not be able to forget to update the dependency but you might run in trouble if your library breaks you code.

It really depends of you workflow. If the library and the repository are tightly coupled, choose git subtree, if you want strict control of your dependancy, choose a dependy manager-like, if not choose git submodules.

GlinesMome
  • 127
  • 3
0

I think that would be a great idea because it will keep things nice and neat for the humans that would have to read it. I usually use sub-directories with my code to make it more human readable. Not using human readable code gives me a headache and makes looking for things very hard. The best thing you can do is put the main executable file in the home directory and break everything else up. Good luck!

XiKuuKy
  • 121
  • 6