第三方图书馆致力于svn：最好检查多个文件或拉链？

Question

当将第三方库提交给源代码控制时，我经常将其作为一个存档来完成，并将解压缩作为构建步骤完成。我想这可能会涉及到数以千计的文件，并且它们不会发生变化，因此将它们全部分开存储似乎需要大量的开销。

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

我无法在网上找到任何在Subversion存储库中添加大量数据（如果是一个我正在升级的数据库，数万个）的文件存在缺陷的问题。除了占用更多空间（超过1 GB，而不是250 MB），有没有人知道我应该犹豫将整个库作为单独的文件提交？

Answer 1

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

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

这有几个好处：

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