如何处理不同布局的Visual Studio解决scheme中的Git子模块?

我们使用Visual Studio 2010(使用C#)进行开发,并从SVN迁移到GIT。 现在我们尝试将我们的仓库(这是相当大的~30,000个文件)分割成许多git仓库 – 每个解决scheme都有一个仓库。 这些解决scheme共享一些项目,大多是我们内部开发的图书馆,并希望从所有解决scheme中增加。

新的版本库有一个平面布局。 每个项目的一个子目录(共享项目是子模块)。 在大旧的回购,项目是在一个树状结构。

外部引用在子模块中出现问题。 在新的版本中,引用项目的path可能是“…… libs \ someproject”,而在新版本中,正确的path是“.. \ someproject”。

我们已经有了一些关于这个的编辑大战,而且不再热衷于这个。

我可以想到的一半解决scheme:

  • 在… csproj.user中使用“引用path”,并从版本控制中排除此文件(必须对每个开发者重做,并且在每次重新清理之后)

  • 在每一种情况下都使用分支机构,并且试图教导每个人“真正的”承诺应该去的地方以及“环境变化”应该去的地方(子模块已经不是最简单的概念了)

  • embedded二进制文件而不是子模块(但是如何开发对子模块的更改呢?不同的log4net版本呢?)

有谁知道一个理智的解决scheme?

Solutions Collecting From Web of "如何处理不同布局的Visual Studio解决scheme中的Git子模块?"

既然你要求一个理智的解决方案,我只能建议你考虑建立你自己的NuGet服务(请看http://www.MyGet.org获取灵感)

http://nuget.codeplex.com/

如果你走下包管理的路线,考虑OpenWrap。 然而,将包管理工件嵌入到源代码中是一个坏主意。 您可以使用这些工具来更新子模块中实际存储的内容,但不要在构建时依赖它们。 从构建脚本的角度来看,预计二进制文件将在那里。

所以,如果我正确地理解你,问题是与Visual Studio,而不是与Git? 如果是这种情况,请使用与Visual Studio一起工作的旧树结构。 使你的子模块也构成一个树形结构。 因此,树的顶部将是一个超级回购,其子模块(分支)将具有自己的子模块,直到你到树的叶子。 一开始设置会很痛苦,但它应该工作。

使用一个子模块来容纳所有的“通用库”。 只是一个级别。 但是你应该把公共图书馆作为明确的合同来提供服务。 通过这种方式,您可以逐渐推出新版本,而无需停机。 这样你只有一个拥有合同的子模块。 这些可能是接口或消息。

我有一个类似的问题使用VS 2013。

我想直接使用git-svn而不是SVN。 SVN有一个巨大的一套目录。 我无法创建一个包含我们所有的trunk文件夹的git-repository。 总是退出一个错误,并存储库已损坏。 我通过如下方式解决了这个问题:

  1. 使用git-svn,我通过为每个文件夹创建一个git-repository来克隆SVN / trunk所需的文件夹子集。
  2. 创建一个包含我所有的git-svn-cloned文件夹的本地父git仓库。
  3. 每个git-repository都作为一个子模块添加到父git-repository中。

Visual Studio的问题在于,它无法识别打开解决方案的主项目之外的多个项目。 此解决方案位于一个文件夹中,该文件夹包含由Visual Studio认可的唯一文件,即处于git-source控制之下。

我试着设置git-preferences来使用上级父目录作为git-repostitory的位置而不会有任何的差异。