在源代码管理中存储第三方库

Question

应用程序依赖的库是否应该存储在源代码管理中？我的一部分说它应该和另一部分说不。添加一个让整个应用程序相形见绌的20mb库只是因为你依赖它的几个功能（虽然相当重）但感觉不对。你应该只存储jar / dll，甚至是项目的分布式zip / tar吗？

其他人做了什么？

Answer 1

存储10年后构建项目所需的一切。我存储任何库的整个zip发行版，以防万一

2017年编辑： 这个答案年龄不大:-)。如果您仍在使用像蚂蚁或品牌这样的旧东西，则上述内容仍适用。如果您使用更现代的东西，如maven或graddle（或者例如Nuget on .net），使用依赖关系管理，除了版本控制服务器之外，您还应该运行依赖关系管理服务器。只要您对两者都有良好的备份，并且您的依赖关系管理服务器不删除旧的依赖关系，您应该没问题。有关依赖关系管理服务器的示例，请参阅示例Sonatype Nexus或JFrog Artifcatory等。

Answer 2

除了在您的存储库中拥有第三方库之外，还值得以这样的方式进行操作，以便在将来更新库中轻松跟踪和合并（例如，安全修复程序等）。如果您使用适当的vendor branch使用Subversion是值得的。

如果你知道在你修改你的第三方代码之前是一个寒冷的日子，那么（正如@Matt Sheppard所说）外部是有意义的并且给你额外的好处，它变得非常容易如果需要安全更新或必备的新功能，请切换到最新版本的库。

此外，您可以在更新代码库时跳过外部，以便在需要长时间缓慢加载时保存。

@Stu Thompson提到在源代码管理中存储文档等。在更大的项目中，我将整个“客户”文件夹存储在源代码管理中，包括发票/账单/会议纪要/技术规格等。整个射击比赛。虽然，嗯，请记住将它们存储在SEPARATE存储库中，而不是将其提供给：其他开发人员;客户端;你的“浏览器源视图”......咳嗽...... :)

Answer 3

不要存储库;他们并没有严格地说你的项目的一部分，并且在你的修订控制系统中占用空间。但是，请使用maven（或Ivy用于ant构建）来跟踪项目使用的外部库的版本。您应该在组织内运行repo的镜像（备份），以确保始终拥有您所控制的依赖项。这应该给你两全其美;项目外部的外部罐子，但仍然可靠且可集中访问。

Answer 4

我们将库存储在源代码管理中，因为我们希望能够通过简单地签出源代码并运行构建脚本来构建项目。如果您无法获得最新信息并且只需一步构建，那么您以后就会遇到问题。

Answer 5

永远不要将第三方二进制文件存储在源代码管理中。源控制系统是支持并发文件共享，并行工作，合并工作和更改历史记录的平台。源代码管理不是二进制文件的FTP站点。第三方程序集不是源代码;他们每个SDLC可能会改变两次。希望能够清理您的工作区，从源代码控制和构建中删除所有内容并不意味着第三方程序集需要卡在源代码管理中。您可以使用构建脚本来控制从分发服务器中提取第三方程序集。如果您担心控制应用程序的哪个分支/版本使用特定的第三方组件，那么您也可以通过构建脚本来控制它。人们已经提到了Maven for Java，你可以用MSBuild为.Net做类似的事情。

Answer 6

我通常将它们存储在存储库中，但我确实同情你希望保持尺寸不变。

如果你不将它们存储在存储库中，绝对需要以某种方式存档和版本化，并且你的构建系统需要知道如何获取它们。 Java世界中很多人似乎都使用Maven自动获取依赖关系，但我没有使用过I，所以我不能真正推荐或支持它。

一个好的选择可能是保留第三方系统的单独存储库。如果您使用的是Subversion，则可以使用subversion的外部支持来自动检出另一个存储库中的库。否则，我建议保留一个内部匿名FTP（或类似）服务器，您的构建系统可以自动从中获取需求。显然，您需要确保保留所有旧版本的库，并将所有内容与存储库一起备份。

Answer 7

我所拥有的是一个类似于Intranet Maven的存储库，其中存储了所有第三方库（不仅是库，而且它们各自的源代码分发包含文档，Javadoc和所有内容）。原因如下：

1. 为什么将未更改的文件存储到专门用于管理更改文件的系统中？
2. 它大大加快了结账时间
3. 每当我看到存储在源代码管理下的“something.jar”时，我会问“它是哪个版本的？”

Answer 8

我将除JDK和IDE之外的所有内容放在源代码管理中。

Tony的理念是合理的。不要忘记数据库创建脚本和数据结构更新脚本。在wiki出现之前，我曾经将文档存储在源代码控制中。

Answer 9

我的首选是将第三方库存储在依赖存储库（例如Artifactory Maven）中，而不是将它们保存在Subversion中。

由于第三方库不像源代码那样进行管理或版本化，因此将它们混合起来并没有多大意义。远程开发人员也欣赏不必通过慢速WPN链接下载大型库，因为他们可以从任意数量的公共存储库中更轻松地获取它们。

Answer 10

在之前的雇主处，我们存储了在源代码管理中构建应用程序所需的所有内容。启动新的构建计算机需要与源代码控制同步并安装必要的软件。

Answer 11

存储库！存储库应该是随时构建项目所需内容的快照。由于项目需要不同版本的外部库，因此您需要更新/检查这些库的较新版本。这样，如果您必须修补旧版本等，您将能够使用旧快照获得所有正确版本。

Answer 12

就个人而言，我有一个dependancies文件夹作为我项目的一部分，并在那里存储引用的库。

我发现这使得生活变得更加容易，因为我在许多不同的项目上工作，通常需要相同版本的库，这意味着更新到给定库的最新版本并不总是可行的。 / p>

在编译时为每个项目使用所有依赖项意味着在事情发生后的几年内，我仍然可以构建项目的任何部分而不必担心破坏其他部分。升级到新版本的库只是替换文件和重建相关组件的一种情况，如果需要，不需要太难管理。

话虽如此，我发现我参考的大多数库都相对较小，重量在几百kb左右，很少大，这使我只需将它们放在源代码控制中就不会有问题。

Answer 13

将第三方库存储在源代码管理中，以便在将代码检出到新的开发环境时可以使用它们。您在构建脚本中可能具有的任何“包含”或构建命令也应引用这些“本地”副本。

除了确保您依赖的第三方代码或库始终可供您使用外，还应该意味着当新开发人员加入团队时，代码（几乎）已准备好在新PC或用户帐户上构建。

Answer 14

使用git子项目，以及来自第三方库的主git存储库的引用，或者（如果它没有）为每个所需的库创建一个新的git存储库。没有任何理由说明为什么你只限于一个git存储库，我不建议你将别人的项目仅仅用作你自己的目录。

Answer 15

存储构建项目所需的所有内容，这样您就可以查看并构建而无需执行任何操作。

（并且，作为经历过这种痛苦的人 - 请保留一份所需的一切，以便安装控件并在开发平台上工作。我曾经有一个可以构建的项目 - 但是没有安装文件和注册码，您无法对第三方控件布局进行任何更改。这是一个有趣的重写）

Answer 16

您必须存储构建项目所需的一切。 此外，您的代码的不同版本可能对第三方具有不同的依赖性。 您需要将代码与其第三方依赖关系一起分支到维护版本......

Answer 17

我个人所做的并且迄今为止喜欢的结果是将库存储在一个单独的存储库中，然后通过使用Subversion svn：externals功能链接到我在其他存储库中需要的每个库。这很好用，因为我可以在源代码控制中保留大多数库（主要是托管的.NET程序集）的版本化副本，而不会增加我们主要源代码库的大小。以这种方式将程序集存储在存储库中使得构建服务器不必安装它们来进行构建。我会说，在没有安装Visual Studio的情况下获得一个构建成功是一件非常繁琐的工作，但是现在我们已经开始工作了，我们很高兴。

请注意，我们目前不使用许多商业第三方控件套件或类似的东西，所以我们没有遇到许可问题，可能需要在构建服务器上实际安装SDK，但我可以看看哪里容易成为一个问题。不幸的是，我没有解决方案，并计划在我第一次遇到它时解决它。