0

在将第三方库提交到源代码控制时，我经常将其作为存档，并将解压缩作为构建步骤。我想这个想法是可能涉及数千个文件，并且预计它们不会改变，因此将它们全部单独存储似乎有很多开销。

不幸的是，这种方法有时会让人头疼，包括在进行完整构建时，开发人员必须等待解压缩。有时依赖检查（以查看是否需要解压缩）无论出于何种原因都不能可靠地工作。

我在网上找不到任何关于向 Subversion 存储库添加大量（在我当前正在升级的一个库的情况下，数万个）文件是否存在缺点的信息。除了占用更多空间（超过 1 GB，而不是小于 250 MB）之外，还有什么理由让人们知道我应该犹豫将整个库作为单独的文件提交？

4

1 回答 1

2

这是Java还是C还是什么类型的开发？

无论哪种方式，您都可以使用Artifactory来存储第三方库而不是源代码控制。如果是 Java，请使用 Maven 或 Ant 和 Ivy。如果是 C 或 C++，请使用 wget 或 curl 获取 Makefile 中的第三方库。要存储它们，您可以使用 Maven 的 deploy:deploy-file 将它们放入存储库。或者，如果您使用 Jenkins，您可以使用 Jenkins 的内置功能与 Maven 存储库对话来为您完成任务。

这有几个优点：

  • 您可以更好地跟踪版本编号。当第三方库被检入存储库时，人们会忘记那是什么版本。例如，您foo.so将 1.2 版签入到您的存储库中。一年后，你不记得它是哪个版本了。其他人决定签入新版本的foo.so. 再一次，你开始失去你所拥有的。由于这是一个编译依赖项，因此您需要知道。
  • 即使这些是自行生成的第三方依赖项，（您有一个构建foo.so用于其他项目的项目），最好将它们存储在像 Artifactory 这样的发布存储库中。同样，您跟踪版本控制。
  • 删除过时的第三方依赖项很容易。在 Subversion 中，即使您svn rm对文件执行了操作，依赖项仍保留在存储库中。节省大量磁盘空间。
  • 您不必担心在构建中保留过时的第三方文件的依赖膨胀，因为您不知道是否需要它们。由于您必须指定每个依赖项，因此开发人员更容易跟踪。
于 2012-05-30T23:11:48.150 回答