在VCS中存储.jar文件的最佳实践（SVN，Git，…）

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

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

在VCS（SVN，Git，…）中存储.jar文件的最佳做法：不要。

它可以在像SVN这样的CVCS（集中式VCS）中有意义，它可以处理数百万个文件，无论它们的大小如何。

它不在DVCS中，特别是像Git（及其限制）：

二进制文件不适合VCS 。
默认情况下，克隆DVCS仓库将获得所有历史记录，包括所有jar版本。
这将是缓慢的并占用大量的磁盘空间，无论这些jar的压缩程度如何。
您可以尝试使用浅层克隆，但这非常不实用。

使用第二个存储库（如Nexus ）存储这些jar，并仅引用txt文件（或Maven项目的pom.xml文件）以获取正确的jar版本。
工件仓库更适合分发和发布管理目的。

总而言之，如果你必须将jar存储在Git仓库中，我建议最初以压缩格式存储它们（这是jar的默认格式：请参阅创建JAR文件）
压缩和未压缩格式都将被Git视为二进制格式，但至少在压缩格式中，克隆和结帐将花费更少的时间。

但是，很multithreading都提到了以非压缩格式存储jar的可能性：

我正在使用一些repos，它会定期检查50MB的tarball。
我说服他们不压缩tarball，git在它们之间进行delta压缩是相当不错的工作（虽然它需要相当多的RAM才能这样做）。

你在Git上有更多关于detified对象的信息：

如果你正在处理二进制或文本，它没有任何区别;

增量不一定与先前版本中的相同路径相同，因此即使添加到历史记录中的新文件也可以以经过筛选的形式存储;

当使用存储在经过整理的表示中的对象时，与在压缩的基本表示中使用相同的对象相比，它将产生更多的成本。完成机制需要权衡这一成本以及空间效率。

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

建议：未压缩 。

您可以使用类似的解决方案，如“解压缩OpenOffice文件，以便在版本控制中更好地存储”这一问题，例如使用clean / smudge gitattribute，使用rezip作为filter来存储未压缩的*.jar文件。

.jar文件已经（可以）压缩，第二次压缩它们可能不会产生你期望的尺寸改进。