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.

Answer 4

Use one submodule to house all "common libraries". Just one level. But you should move the common libraries as services with well defined contracts. This way you can incrementally rollout new versions with no down time. This way you only have a submodule in each that holds the contracts. These could be interfaces or messages.

Answer 5

I have a similar problem using VS 2013.

I want to use git-svn instead of SVN directly. SVN has a gigantic set of directories. I could not create a single git-repository that would contain all of our trunk folder. Git-always exited with an error and the repository was corrupted. I worked around the problem by doing as follows:

1. Using git-svn, I cloned the subset of folders off SVN/trunk that I needed by creating one git-repository per folder.
2. Created a local parent git repository that contains all my git-svn-cloned folders.
3. Each git-repository was added as a sub-module to the parent git-repository.

The problem with Visual Studio is that it does not recognize the multiple projects outside the main project where I opened the solution. This solution is in a folder that contains the only files recognized by Visual Studio as being under git-source control.

I tried setting the git-preferences to use the upper level parent directory as the location of the git-repostitory without noticing any difference.