How to deal with Git Submodules in Visual Studio solutions with different layout?

Question

We develop with Visual Studio 2010 (in C#) and migrated a while ago from SVN to GIT. Now we try to split up our repository (which is quite big - ~30.000 files) to many git repositories - one for each solution. The solutions share some projects, mostly libraries we develop in-house and like to add to from all the solutions.

The new repositories have a flat layout. One subdirectory for each project (shared projects are submodules). In the big old repo, the projects are in a tree structure.

The Problem occurs with external references in the submodules. In the new repos, the path to a referenced project may be "......libs\someproject", while in the new layout the correct path would be "..\someproject".

We already had some edit wars concerning this and are not keen on more.

Half-baked Solutions I could think of:

• use "Reference Paths" in ...csproj.user and exclude this file from version control (has to be redone for each developer and after each reopsitory cleanup)

• use branches for each situation and try to teach everyone where "real" commits should go and where "environment-change" commits should go (submodules are already not the simplest concept...)

• embed binaries instead of the submodules (but what about developing changes to the submodules? what about different log4net versions?)

Does anyone know of a sane solution?

Answer 1

Since you are asking for a sane solution, I can only advise you to look into setting up your own NuGet service (look at http://www.MyGet.org for inspiration)

http://nuget.codeplex.com/

Answer 2

IF you go down the route of package management, consider OpenWrap. However, embedding the package management artefacts in source code is a bad idea. You can use such tools to update what is actually stored in submodules, but don't rely on them at build time. Expect the binaries to be there from the point of view of your build scripts.

Answer 3

So if I understand you correctly, the problem is with Visual Studio and not with Git? If that's the case, use the old tree structure that worked with Visual Studio. Make your submodules structure a tree structure too. So the top of the tree would be one super repo whose sub modules (the branches) would have submodules of their own, until you get down to the leaves of your tree. It would be a pain to setup at first, but it should just work.