java - 在 VCS(SVN、Git、...)中存储 .jar 文件的最佳实践

Question

我知道，在 Maven 时代，不建议将库存储在 VCS 中，但有时它是有意义的。

我的问题是如何最好地存储它们 - 压缩或未压缩？未压缩的它们更大，但如果它们被新的替换了几次，那么两个未压缩的 .jar 文件之间存储的差异可能会比压缩文件的差异小得多。有人做过测试吗？

Answer 1

在 VCS(SVN、Git 等)中存储 .jar 文件的最佳做法:不要。

这在像 SVN 这样的 CVCS(集中式 VCS)中是有意义的，它可以处理数百万个文件，无论文件大小。

它不在 DVCS 中，尤其是像 Git(和 its limits)这样的:

• 二进制文件 don't fit well with VCS .
• 默认情况下，克隆 DVCS 存储库将为您提供所有其历史记录以及所有 jar 版本。
  无论这些 jar 压缩得多么好，这都会很慢并且会占用大量磁盘空间。
  您可以尝试使用 shallow cloning ，但这是非常不切实际的。

使用第二个存储库，例如 Nexus ，用于存储这些 jar，并且仅引用 txt 文件(或 pom.xml 文件 Maven 项目)以获取正确的 jar 版本。
工件 repo 更适合 distribution and release management purpose 。

---

话虽如此，如果您必须将 jar 存储在 Git 存储库中，我会建议最初以压缩格式存储它们(这是 jar 的默认格式:参见 Creating a JAR File)
压缩和未压缩的格式都将被 Git 视为二进制文件，但至少，在压缩格式中，克隆和 checkout 将花费更少的时间。

但是，许多线程提到了 store jar in uncompressed format 的可能性:

I'm using some repos that get regular 50MB tarballs checked into them.
I convinced them to not compress the tarballs, and git does a fairly decent job of doing delta compression between them (although it needs quite a bit of RAM to do so).

你有更多关于 deltified object on Git here :

• It does not make a difference if you are dealing with binary or text;
• The delta is not necessarily against the same path in the previous revision, so even a new file added to the history can be stored in a delitified form;
• When an object stored in the deltified representation is used, it would incur more cost than using the same object in the compressed base representation. The deltification mechanism makes a trade-off taking this cost into account, as well as the space efficiency.

因此，如果克隆和 checkout 不是您必须每 5 分钟执行一次的常见操作，那么在 Git 中以未压缩格式存储 jar 会更有意义，因为:

• Git 会为这些文件压缩/计算增量
• 您最终会在工作目录中找到未压缩的 jar，这些 jar 可能会被更快地加载。

建议:未压缩。