支持和反对包含版本控制中的第三方库的参数？

Question

我最近遇到过很多人说第三方库不属于版本控制。这些人无法向我解释为什么他们还不应该这样做，所以我希望你们能来救我们。）

就个人而言，我认为当我检查一个项目的主干时，它应该只是工作 - 无需去其他网站查找库。通常情况下，您最终会为不同的开发人员提供相同第三方库的多个版本 - 有时会出现不兼容问题。

在那里有一个libs文件夹是不是很糟糕，你可以参考“guarenteed to to-work”库？

Answer 1

在SVN中，有一种模式用于存储名为vendor branches的第三方库。同样的想法适用于任何其他类似SVN的版本控制系统。基本思想是将第三方源包含在其自己的分支中，然后将该分支复制到主树中，以便您可以轻松地在本地自定义上应用新版本。它也干净利落地保持分开。恕我直言，直接在你的树中包含第三方内容是错误的，但供应商分支达到了很好的平衡。

Answer 2

检查库中的源代码控制的另一个原因是我在这里没有提到，它使您能够从特定的快照或版本重建应用程序。这允许您重新创建某人可能报告错误的确切版本。如果您无法重建确切的版本，则可能无法重现/调试问题。

Answer 3

是的，你应该（如果可行的话）。

您应该能够使用新机器并使用尽可能少的步骤构建项目。对我来说，是：

1. 安装IDE（例如Visual Studio）
2. 安装VCS（例如SVN）
3. 结帐
4. 构建

任何事情都必须有充分的理由。

这是一个例子：我有一个项目使用Yahoo的YUI压缩器来缩小JS和CSS。 YUI .jar文件在源代码管理中进入项目旁边的tools目录。然而，Java运行时没有 - 这已成为项目的先决条件，就像IDE一样。考虑到JRE的流行程度，这似乎是一个合理的要求。

Answer 4

不 - 我认为您不应该将第三方库放入源代码管理中。线索的名称是“源代码管理”。

尽管源代码控制可用于分发和部署，但这不是它的主要功能。你应该能够检查你的项目并让它工作的论点是不现实的。总有依赖关系。在一个Web项目中，它们可能是Apache，MySQL，编程运行时本身，比如Python 2.6。你不会把所有这些都堆在你的代码库中。

额外的代码库是一样的。不是将它们包含在源代码控制中以便于部署，而是创建一个部署/分发机制，允许轻松获取和安装所有依赖项。这使得签出和运行软件的步骤如下：

• 安装VCS
• 同步代码
• 运行安装脚本（下载并安装所有依赖项的正确版本）

为了给出一个具体的例子（我意识到这是以网络为中心的），Python Web应用程序可能包含一个requirements.txt文件，其中包含：

simplejson == 1.2
django的== 1.0
otherlibrary == 0.9

通过pip运行它并完成工作。然后，当您想要升级到使用Django 1.1时，您只需更改需求文件中的版本号并重新运行设置。

Answer 5

第三方软件的来源不属于（除了可能作为静态参考），但编译后的二进制文件不属于。

如果您的构建过程将编译程序集/ dll / jar /模块，那么只将第三方源代码保留在源代码管理中。

如果你不编译它，那么把二进制程序集/ dll / jar /模块放到源代码控制中。

Answer 6

这可能取决于您拥有的语言和/或环境，但对于我正在处理的项目，我在源代码管理中没有放置库（jar文件）。它有助于使用Maven等工具为您提取必要的库。 （每个项目都维护一个必需的jar列表，​​Maven会自动从公共存储库中提取它们 - http://repo1.maven.org/maven2/）

话虽这么说，如果您没有使用Maven或其他一些管理和自动获取必要库的方法，请务必将它们检入您的版本控制系统。如有疑问，请务必谨慎。

Answer 7

我过去倾向于处理这个问题的方法是采用第三方库的预编译版本并检查版本控制以及头文件。我们不是将源代码本身检查到版本控制中，而是将其存档到定义的位置（服务器硬盘驱动器）。

这种方式为您提供了两全其美的效果：一步获取过程可以获取您需要的所有内容，但它不会让您的版本控制系统陷入困境，需要一堆必要的文件。此外，通过获取预编译的二进制文件，您可以跳过编译阶段，从而加快构建速度。

Answer 8

您应该明确地将第三方库置于源代码管理之下。此外，您应该尽量避免依赖安装在各个开发人员计算机上的东西。原因如下：

• 然后，所有开发人员将共享相同版本的组件。这非常很重要。
• 您的构建环境将变得更加便携。只需在新机器上安装源代码控制客户端，下载您的存储库，构建就可以了（理论上，至少:)）。
• 有时很难获得某个库的旧版本。将它们保持在源代码管理之下可确保您不会遇到此类问题。

但是，如果您不打算更改代码，则无需在存储库中添加第三方源代码。我倾向于添加二进制文件，但我确保在我们的代码中只引用了这些库（例如，不是来自Windows GAC的库）。

Answer 9

我们这样做是因为我们希望在将它与我们的代码集成之前测试供应商分支的更新版本。我们在测试新版本时会对此进行更改。我们的理念是，运行应用程序所需的一切都应该在SVN中，以便

1. 您可以启动并运行新的开发人员
2. 每个人都使用相同版本的各种库
3. 我们可以准确地知道在给定时间点当前的代码是什么，包括第三方库。

Answer 10

不，在您的存储库中拥有第三方代码并非战争罪，但我发现这会破坏我的审美感。这里的许多人似乎认为让整个开发团队使用这些依赖项的相同版本是件好事。我说这是一种责任。您最终依赖于该依赖项的特定版本，稍后使用其他版本会更加困难。我更喜欢异构开发环境 - 它会强迫您将代码与特定版本的依赖项分离。

恕我直言，保留依赖关系的正确位置在您的磁带备份上，如果您有，则在您的托管存款中。如果您的特定项目需要它（并且项目在这方面并不完全相同），那么还要在您的版本控制系统下保留一个链接到这些特定版本的文档。

Answer 11

我喜欢将第三方二进制文件检查到包含任何外部依赖项的“lib”目录中。毕竟，您想要跟踪这些库的特定版本吗？

当我自己编译二进制文件时，我经常会在二进制文件旁边检查代码的压缩副本。这清楚地表明代码不适合编译，操作等。我几乎永远不需要返回并引用压缩代码，但有几次它是有帮助的。

Answer 12

如果我可以逃脱它，我会将它们从我的版本控制中移出我的文件系统。最好的情况是jQuery，我将使用Google的AJAX库并从那里加载它：

<script src="http://ajax.googleapis.com/ajax/libs/jquery/1/jquery.min.js" type="text/javascript"></script>

我的下一个选择是使用Git Submodules之类的东西。如果这些都不够，那么它们最终会受到版本控制，但在那时，它只是和你一样最新......