在VCS中存储.jar文件的最佳做法（SVN，Git，...） [英] Best practice to store .jar files in VCS (SVN, Git, ...)

问题描述

我知道，在Maven的时候，不建议将库存储在VCS中，但有时它是有道理的。但是，我的问题是如何获得最佳效果存储他们 - 压缩还是未压缩？未压缩的它们更大，但如果它们被更新的版本替换了几次，那么两个未压缩的.jar文件之间存储的差异可能比压缩的差异小得多。是否有人进行了一些测试？

解决方案

最佳做法是在VCS中存储.jar文件（SVN，Git，...） t。

像SVN这样的CVCS（集中化VCS）可以处理数百万个文件，无论大小如何。

它不在DVCS中，尤其是像Git（和它的极限）：

• 二进制文件不适合VCS 。
  
• 默认情况下，克隆DVCS回购将所有的jar版本都可以获得它的历史记录。
  
  这将会很慢并且占用大量的磁盘空间，不管这些jar被压缩得多么好。 >
  您可以尝试使用浅拷贝，但这是非常不切实际的。
使用第二个存储库，如 Nexus ，用于存储这些jar文件，并且只引用 txt 文件（或 Maven > / a> 项目），以获取正确的jar版本。

一个工件repo更适用于分发和发布管理目的。




---





所有这些都说明了，如果您必须将jar存储在Git仓库中，我会建议先存储它们以压缩格式（这是jar的默认格式：请参阅创建JAR文件）

Git将压缩和未压缩的格式视为二进制文件，但至少以压缩格式将克隆和结账花费的时间会少一些。





然而，很多线索都提到




我正在使用一些可获得常规50MB tarball的回购协议检查到他们。

我说服他们不要压缩tarball，而git在他们之间做delta压缩的工作做得相当不错（尽管这需要相当多的内存来完成）。




您在在Git上分析对象：








• 如果你正在处理二进制或文本的话;


• delta不一定与前一版本中的路径相同，因此即使添加到历史记录中的新文件也可以以已删除的形式存储;


• 当存储在使用已分解的表示形式，它会比在压缩基表示形式中使用相同的对象产生更多的成本。定价机制会考虑到这一成本以及空间效率。








<因此，如果克隆和签出不是常用操作，而且每隔5分钟必须执行一次，那么在Git中以非压缩格式存储jar会更有意义，因为：





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






建议：未压缩。


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

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?

解决方案

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

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

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

• Binary files don't fit well with VCS.
• By default, cloning a DVCS repo will get you all of 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.

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

---

All that being said, if you must store 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.

However, many threads mentions the possibility to 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).

You have more on 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.

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:

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

Recommendation: uncompressed.

这篇关于在VCS中存储.jar文件的最佳做法（SVN，Git，...）的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！