将多GB SVN存储库移至Git

当前，我的公司在SVN存储库中具有Visual Studio隔离，其组织如下：

SolutionFolder (~3.5 GB)
|-> SolutionName.sln
|-> .. Some source code folders... (~250 MB)
|-> ThirdParty (~3 GB)
|-> Tools
    | -> Tool1
    | -> Tool2

Tool1和Tool2是独立构建的（具有自己的解决方案），但是会生成在主要构建中使用的可执行文件。ThirdParty文件夹包含项目的所有依赖项，包括一些预编译的100+ MB .lib文件和大型库（如boost）。

将所有功能都包含在一个SVN存储库中非常方便，这样（1）开发人员只需执行一次签出操作，（2）我们就无需跟踪每个版本的构建所需的依赖项版本。另一方面，要花些时间检查此仓库。

将这个项目结构转移到git的最佳方法是什么？大概最好是从主存储库中排除ThirdParty以及可能的工具，但是我们希望一步就可以轻松下载ThirdParty，并且我们希望对其进行版本控制（并且主存储库和ThirdParty / Tools之间的版本不匹配会很糟糕）。

在这一点上，我对保存历史不感兴趣，只是对如何组织这样的项目不感兴趣。

使用适当的工具进行作业。在Windows中，这意味着

将NuGet用于第三方依赖项

这样，您就可以以版本化的方式保留第三方依赖关系，但是不会用不必要的东西充斥您的存储库。结帐速度更快，并且该项目按原样组织。您可以在Visual Studio中启用一个选项，以便它始终自动下载所有依赖项。

当然，您可以使用仅使用git（另一个回购，子模块等）的解决方案，但这仅仅是黑客。以正确的方式进行操作将很快获得回报，并为您提供面向未来的系统。

注释后编辑：使用NuGet的最佳方法是在共享驱动器或完整nuget服务器上设置本地NuGet源。两种方法的安装时间都不会超过几分钟。这样，您可以确保所需的所有软件包始终可用，无论它们起源于何处。

您可以为工具使用子模块。这样，您可以像现在一样将它们保存在子目录中，并使用单独的存储库对它们进行版本控制。这也意味着您可以克隆（检出）工具并分别进行开发，其他项目也可以依赖这些存储库-以及它们的特定，可审核版本。

您也可以为第三方库使用子模块，但是如果可能的话，我建议为这些库使用依赖项管理器。

您变成git存储库的实体必须是您版本和分支的实体；如果SolutionFolder/Tools/Tool1对应于一件事，那就是实体的级别。这是因为git的关于整个国家的目录树是版本化的实体，而使用SVN有可能（即使不是一个好主意）有一个trunk，branches并tags在树内的任何地方。

派生的文物不应保存在存储库中，外部库也不应保留。有更好的方法来处理这些问题。（如果您使用的是Java，请考虑使用私有的Maven存储库；它们相对易于使用，并且可以与许多其他东西很好地集成。）

如果您习惯于将所有内容都存储在一个存储库中以便于结帐的工作流程，请考虑使用一个脚本来进行设置。

老实说，我不会更改您的设置。这正是我们现在正在做的。我正在设置一个单独的git存储库来处理我们使用的第三方库，但我认为它不会影响可移植性的成本。现在，任何开发人员都可以签出并开始使用，而无需执行任何手动设置步骤。而且我任何构建服务器/从属都可以构建项目。除非您有多个仓库共享第三方工具，否则我将坚持使用当前设置。

我玩的是在单独的仓库中设置第三方工具。然后，我有一个简单的批处理脚本，使用sha1 ref读取文本文件并签出正确的版本。这将允许我为不同的项目使用不同的第三方版本。我是从Facebook Buck构建工具中得到这个想法的。但是最后，许多开发人员不喜欢使用命令行工具（此处为MS VC shop），所以我放弃了这个想法。

为什么在需要时（使用NuGet）不下载第三方库的主要原因之一是，如果您需要长期支持您的产品。在我的行业中，我们有时需要提供依赖于旧的第三方库的旧版本的更新。我们不想花费大量时间来选择可以升级或不能升级的库，而只使用该版本中使用的库。现在，假设您使用NuGet，哎呀...您需要的lib的最新版本是3.98，但您需要的是2.04 .....如何向老板解释，您需要花费两个月的时间来升级旧版本才能在他期望有一个小的改变时使用最新的库！