在版本控制系统（SVN、Git等）中存储.jar文件的最佳实践

Question

22

我知道，在Maven时代不建议将库存储在版本控制系统中，但有时候这样做是有意义的。

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

- Mot

3个回答

4

您可以使用与在此处的SO中找到的答案类似的解决方案，即使用clean/smudgegitattribute，并使用*.jar文件 uncompressed的rezip过滤器进行存储。

- Jakub Narębski

“存储未压缩的存储罐”解决方案的好补充。+1 - VonC

2

.jar文件已经被压缩过了，再次压缩可能不会达到您预期的尺寸改善。

- rsp

2

我并不是想再次压缩它们，而是创建它们的压缩或非压缩版本。 - Mot

1

@mklhmnn，如果您存储.jar文件，我建议保留它们的原始分发格式。从存储库中生成的Jar文件不应添加到存储库中。 - rsp

1

@ZZ Coder：不，一个人可以轻松地创建未压缩的jar和zip文件。例如，为了减小下载大小，建议使用未压缩的jar文件（因为它们可以被打包压缩器更好地压缩）。 - Mot

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- VonC · Accepted Answer

在版本控制系统（SVN、Git等）中存储.jar文件的最佳实践是：不要这样做。

在CVCS（集中式版本控制系统）如SVN中，这可能有意义，因为它可以处理数量巨大的文件，无论其大小如何。

但在DVCS中，特别是像Git这样的系统存在限制：

二进制文件与VCS不兼容。
默认情况下，克隆DVCS repo将获得所有历史记录，包括所有jar版本。
这将会很慢，并占用大量磁盘空间，无论这些jar被压缩得多么好。
你可以尝试使用浅层克隆，但这非常不实用。

使用第二个仓库，例如Nexus，来存储这些jar包，并且只引用一个txt文件（或者对于Maven项目，引用一个pom.xml文件），以便获取正确的jar版本。
艺术品仓库更适用于分发和发布管理目的。

所有这些都说了，如果您必须将jar存储在Git存储库中，我建议最初将它们存储在压缩格式中（这是jar的默认格式：请参阅Creating a JAR File）。无论是压缩还是未压缩格式，Git都将视为二进制文件，但至少在压缩格式中，克隆和检出所需的时间更短。

然而，许多线程提到了可能会以未压缩格式存储jar：

我正在使用一些存储有定期50MB tarball的repo。
我说服他们不要压缩tarball，git在它们之间执行很好的增量压缩（尽管需要相当多的RAM）。

您可以在此处找到更多关于Git上的增量对象的信息：

处理二进制或文本没有区别；

增量不一定针对先前版本中的同一路径，因此即使是添加到历史记录中的新文件也可以以增量形式存储；

当使用以增量形式存储的对象时，它将比在压缩基本表示中使用相同的对象产生更多的成本。增量机制权衡考虑了这个成本以及空间效率。

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

建议：未压缩。