0

In our company we make projects by piling-up several frameworks / libraries: 

/Framework
/Extensions (depends on Framework)
/Business (depends on Framework & Extensions)
/Project A (depends on Framework & Extensions & Business)
/Project B (depends on Framework & Extensions & Business)
/Project C (depends on Framework & Extensions & Business)
/...

So far we are using a big git repository that contains all the projects and frameworks, and we are using git subtree to split just the framework to publish it (it's open source).

We would like be able to split this big repository in it's different projects, but the fact that there are so many recursive dependencies worries me:

AFAIK, both git submodules/git subtrees require that all the library code is inside the main repository, so we will end up with a project structure like this:

/Framework
/Extensions/Framework 
/Business/Extension/Framework
/Project A/Business/Extensions/Framework
/Project B/Business/Extensions/Framework
/Project C/Business/Extensions/Framework

We don't like having so many copies of the framework everywhere, neither the fact that the framework folder gets so deep in the hierarchy.

What we would like is that the Project A respository asserts, on pull, that there's a repository side by side with the current one that contains some SHA, and to check this SHA.

Is there a way to make side by side git submodules/subtrees?

Olmo
  • 4,257
  • 3
  • 31
  • 35

1 Answers1

0

You haven't described your development environment but what you've described doesn't sound a whole lot different from developing code with dependencies in Linux /usr/lib and /usr/include. Lots of projects depend on shared libraries; in order to compile those projects into an executable there needs to be installed, stable version of the libraries (frameworks and extensions) that the projects depend on.

In your case let's assume that Framework, Extensions and Business are all stable (or at least only updated infrequently). You'd have three checkouts like:

cd /stable
git checkout -b version-x.y /path/to/Framework.git
git checkout -b version-x.y /path/to/Extensions.git
git checkout -b version-x.y /path/to/Business.git

performed by every developer in order to get these 'libraries' on their development machine. Each project has build/make instructions that references these libraries. (The references could be absolute as /stable/... or relative to the 'Project X' location.) It is similar for Extensions' dependency on Framework and Business' dependency on Extensions and Framework.

With this approach there is only one of each clone but all the dependencies are in place.

[EDIT] The above won't work if each Project needs to modify that stuff it depends on; if that is the case then you can't avoid cloning everything multiple times. And, in fact, it is preferred to do the cloning, using submodules, to ensure that the changes for one project can be merged back into the master when appropriate.

GoZoner
  • 67,920
  • 20
  • 95
  • 145
  • Unfortunately this is not the case, we change Framework, Extensions and Business continuously from each project (isolated for a while on its own branch) and we like the fact that the changes on this libraries move seamlessly from project to project, without having rigorous versions and being able able to change/debug them easy (they are part of the same solution). – Olmo Jun 21 '12 at 10:54
  • Then the preferred solution is to use submodules which means you must have multiple copies (on each development machine). Having copies is an advantage in this case; it allows each project to succeed and then allows the changes to be merged back in. – GoZoner Jun 21 '12 at 16:37