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

Best practice to store .jar files in VCS (SVN, Git, ...)

提问by Mot

I know, in the time of Maven it is not recommended to store libraries in VCS, but sometimes it makes sense, though.

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

My question is how to best store them - compressed or uncompressed? Uncompressed they are larger, but if they are replaced a couple of times with newer ones, then maybe the stored difference between two uncompressed .jar files might be much smaller than the difference of compressed ones. Did someone make some tests?

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

回答by VonC

Best practice to store .jar files in VCS (SVN, Git, …): don't.

在 VCS（SVN、Git 等）中存储 .jar 文件的最佳实践：不要。

It could make sense in a CVCS (Centralized VCS) like SVN, which can handle millions of files whatever their size is.

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

It doesn't in a DVCS, especially one like Git (and its limits):

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

• Binary files don't fit well with VCS.
• By default, cloning a DVCS repo will get you allof its history, with all the jar versions.
  That will be slow and take a lot of disk space, not matter how well those jar are compressed.
  You could try to play with shallow cloning, but that's highly unpractical.

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

Use a second repository, like Nexus, for storing those jars, and only reference a txtfile (or a pom.xmlfile for Mavenproject) in order to fetch the right jar versions.
A artifact repo is more adapted for distribution and release management purpose.

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

---

---

All that being said, if you muststore jar in a Git repo, I would have recommend initially to store them in their compressed format (which is the default format for a jar: see Creating a JAR File)
Both compressed and uncompressed format would be treated as binary by Git, but at least, in a compressed format, clone and checkout would take less time.

话虽如此，如果您必须将 jar 存储在 Git 存储库中，我建议最初以压缩格式存储它们（这是 jar 的默认格式：请参阅创建 JAR 文件）
压缩和未压缩格式都将是Git 将其视为二进制文件，但至少，在压缩格式中，克隆和检出将花费更少的时间。

However, many threads mentions the possibility to store jar in uncompressed format:

但是，许多线程提到了以未压缩格式存储 jar的可能性：

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).

我正在使用一些可以将常规 50MB tarball 签入其中的存储库。
我说服他们不要压缩 tarball，并且 git 在它们之间进行增量压缩方面做得相当不错（尽管这样做需要相当多的 RAM）。

You have more on deltified object on Git here:

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

• 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.

• 如果您处理二进制或文本，这没有区别；
• delta 不一定与上一版本中的路径相同，因此即使添加到历史记录中的新文件也可以以 delitified 形式存储；
• 当使用存储在 deltified 表示中的对象时，与在压缩的基本表示中使用相同的对象相比，它会产生更多的成本。Deltification 机制在考虑此成本以及空间效率的情况下进行权衡。

So, if clones and checkouts are not common operations that you would have to perform every 5 minutes, storing jar in an uncompressed format in Git would make more sense because:

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

• Git would compressed/compute delta for those files
• You would end up with uncompressed jar in your working directory, jars which could then potentially be loaded more quickly.

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

Recommendation: uncompressed.

建议：未压缩的.

回答by Jakub Nar?bski

You can use similar solution as found in answers to "Uncompress OpenOffice files for better storage in version control"question here on SO, namely using clean / smudgegitattributeusing rezipas filter to store *.jarfiles uncompressed.

您可以使用在 SO上的“解压缩 OpenOffice 文件以更好地存储在版本控制中”问题的答案中找到的类似解决方案，即使用清理/涂抹gitattribute使用rezip作为过滤器来存储*.jar未压缩的文件。

回答by rsp

.jarfiles are (can be) compressed already, compressing them a second time probably will not yield the size improvement you expect.

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