应用程序依赖的库是否应该存储在源代码管理中？我的一部分说应该，另一部分说不。添加一个使整个应用程序相形见绌的 20mb 库感觉是错误的，因为您依赖其中的几个函数（尽管相当严重）。您应该只存储 jar/dll 还是项目的分布式 zip/tar？
其他人做什么？
graham.reeds
问问题
19712 次
17 回答
51
存储 10 年后构建项目所需的一切。我存储任何库的整个 zip 分发，以防万一
2017 年的编辑：这个答案并不成熟:-)。如果您仍在使用诸如 ant 或 make 之类的旧东西，则上述内容仍然适用。如果您使用更现代的东西，如 maven 或 graddle（或 .net 上的 Nuget），使用依赖管理，除了版本控制服务器之外，您还应该运行依赖管理服务器。只要您对两者都有良好的备份，并且您的依赖项管理服务器不会删除旧的依赖项，您应该没问题。有关依赖管理服务器的示例，请参见Sonatype Nexus或JFrog Artifcatory等。
于 2008-09-08T05:28:00.050 回答
29
除了在您的存储库中拥有第三方库外，还值得以一种便于跟踪和合并库的未来更新（例如，安全修复等）的方式进行。如果您使用的是 Subversion，则值得使用适当的供应商分支。
如果您知道在修改第三方代码之前将是一个寒冷的日子，那么（正如@Matt Sheppard 所说）外部是有意义的，并为您带来额外的好处，即它变得非常容易切换到最新版本的库应该安全更新或必须具备的新功能使其成为可取的。
此外，如果您需要，您可以在更新代码库时跳过长时间的缓慢加载过程，从而跳过外部。
@Stu Thompson 提到在源代码管理中存储文档等。在更大的项目中，我将整个“客户”文件夹存储在源代码控制中，包括发票/账单/会议记录/技术规范等。整个拍摄比赛。虽然，咳咳，请记住将这些存储在一个单独的存储库中，与您将提供给的存储库分开：其他开发人员；客户端; 你的“浏览器源代码视图”......咳嗽...... :)
于 2008-09-08T08:48:18.617 回答
19
我们将库存储在源代码控制中，因为我们希望能够通过简单地检查源代码并运行构建脚本来构建项目。如果您无法获得最新版本并一步构建，那么您以后只会遇到问题。
于 2008-09-08T05:41:33.777 回答
13
永远不要将您的 3rd 方二进制文件存储在源代码管理中。源代码控制系统是支持并发文件共享、并行工作、合并工作和更改历史的平台。源代码管理不是二进制文件的 FTP 站点。3rd 方程序集不是源代码；每个 SDLC 它们可能会更改两次。希望能够清理您的工作区，从源代码管理中删除所有内容并构建并不意味着需要将第 3 方程序集卡在源代码管理中。您可以使用构建脚本来控制从分发服务器中拉取第 3 方程序集。如果您担心控制应用程序的哪个分支/版本使用特定的 3rd 方组件，那么您也可以通过构建脚本来控制它。人们提到 Maven for Java，你可以用 MSBuild for .Net 做类似的事情。
于 2009-01-05T20:24:35.600 回答
8
我通常将它们存储在存储库中，但我对您希望减小大小的愿望表示同情。
如果您不将它们存储在存储库中，则绝对需要以某种方式存档和版本化，并且您的构建系统需要知道如何获取它们。Java 世界中的很多人似乎都使用 Maven 来自动获取依赖项，但我没有使用过 I，所以我不能真正推荐或反对它。
一个不错的选择可能是保留第三方系统的单独存储库。如果您使用的是 Subversion，则可以使用 subversion 的外部支持自动检查来自其他存储库的库。否则，我建议保留一个内部匿名 FTP（或类似）服务器，您的构建系统可以自动从中获取需求。显然，您需要确保保留所有旧版本的库，并将其中的所有内容与您的存储库一起备份。
于 2008-09-08T07:58:54.913 回答
5
我所拥有的是一个类似于 Intranet Maven 的存储库，其中存储了所有 3rd 方库（不仅是库，还有它们各自的源代码分发以及文档、Javadoc 和所有内容）。原因如下：
- 为什么要将不会更改的文件存储到专门用于管理更改文件的系统中？
- 它大大加快了结账速度
- 每次我看到存储在源代码管理下的“something.jar”时，我都会问“它是哪个版本？”
于 2008-09-15T22:01:22.163 回答
4
我将除 JDK 和 IDE 之外的所有内容都放在源代码管理中。
托尼的哲学是正确的。不要忘记数据库创建脚本和数据结构更新脚本。在 wiki 出现之前，我什至将我们的文档存储在源代码管理中。
于 2008-09-08T05:40:48.130 回答
4
我的偏好是将第三方库存储在依赖库中（例如Artifactory with Maven），而不是将它们保存在 Subversion 中。
由于第三方库不像源代码那样进行管理或版本控制，因此将它们混合在一起没有多大意义。远程开发人员也很高兴不必通过慢速 WPN 链接下载大型库，因为他们可以更轻松地从任意数量的公共存储库中获取它们。
于 2008-09-15T17:01:50.103 回答
2
在以前的雇主中，我们将构建应用程序所需的一切都存储在源代码控制中。启动一台新的构建机器需要与源代码控制同步并安装必要的软件。
于 2008-09-15T16:40:22.417 回答
1
将第三方库存储在源代码管理中，以便在您将代码签出到新的开发环境时使用它们。您在构建脚本中可能拥有的任何“包含”或构建命令也应该引用这些“本地”副本。
除了确保您始终可以使用您所依赖的第三方代码或库外，这还应该意味着当新开发人员加入团队时，代码（几乎）可以在新的 PC 或用户帐户上构建。
于 2008-09-08T05:45:45.857 回答
1
存储库！存储库应该是随时构建项目所需内容的快照。由于项目需要不同版本的外部库，您需要更新/签入这些库的较新版本。这样，如果您必须修补旧版本等，您将能够获得与旧快照一起使用的所有正确版本。
于 2008-09-08T06:12:05.357 回答
1
就我个人而言，我有一个依赖文件夹作为我的项目的一部分，并在其中存储引用的库。
我发现这让我的生活更轻松，因为我在处理许多不同的项目，通常需要相同版本的库的相互依赖的部分，这意味着更新到给定库的最新版本并不总是可行的。
在每个项目的编译时使用所有依赖项意味着几年后事情发生了变化，我仍然可以构建项目的任何部分，而不必担心破坏其他部分。升级到新版本的库只是替换文件和重建相关组件的情况，如果需要，管理起来并不难。
话虽如此，我发现我引用的大多数库都相对较小，大约只有几百 kb，很少会变大，这让我将它们放在源代码控制中变得不成问题。
于 2008-12-12T16:00:27.647 回答
1
使用 git 子项目，或者从第 3 方库的主 git 存储库中引用，或者（如果没有）为每个所需的库创建一个新的 git 存储库。没有任何理由将您仅限于一个 git 存储库，我不建议您将其他人的项目仅用作您自己的目录。
于 2010-06-08T00:24:06.423 回答
0
存储构建项目所需的所有内容，因此您无需执行任何操作即可检查并构建。
（并且，作为经历过痛苦的人 - 请保留安装控件并在开发平台上工作所需的所有内容的副本。我曾经有一个可以构建的项目 - 但没有安装文件和注册密钥，你可以不要对第三方控件布局进行任何更改。这是一个有趣的重写）
于 2008-09-08T06:18:44.937 回答
0
您必须存储构建项目所需的一切。此外，您的代码的不同版本可能对第 3 方有不同的依赖关系。您需要将代码及其第 3 方依赖项一起分支到维护版本中......
于 2008-12-12T15:50:21.757 回答
0
就个人而言，我所做的并且到目前为止喜欢的结果是将库存储在单独的存储库中，然后通过使用 Subversion svn:externals 功能链接到我在其他存储库中需要的每个库。这很好用，因为我可以在源代码控制中保留我们大多数库（主要是托管的 .NET 程序集）的版本副本，而不会增加我们主要源代码存储库的大小。以这种方式将程序集存储在存储库中使得构建服务器不必安装它们来进行构建。我会说，在没有安装 Visual Studio 的情况下让构建成功是一件苦差事，但现在我们让它工作了，我们对它很满意。
请注意，我们目前没有使用很多商业第三方控制套件或类似的东西，所以我们没有遇到许可问题，可能需要在构建服务器上实际安装 SDK，但我可以看到在哪里很容易成为问题。不幸的是，我没有解决方案，并计划在我第一次遇到它时解决它。
于 2011-06-23T11:44:00.683 回答