在VCS中存储.jar文件的最佳实践(svn、git…)

在VCS中存储.jar文件的最佳实践(svn、git、_):不要。

这在像SVN这样的CVC(集中式VCS)中是有意义的,它可以处理数以百万计的文件,无论文件大小如何。

它不在DVC中,特别是像Git这样的 its limits ):

• 二进制文件 don't fit well with VCS .
• 默认情况下,克隆dvcs repo将获得 全部的 它的历史,以及所有的JAR版本。
  这将很慢,并且占用大量的磁盘空间,而不管这些jar压缩得有多好。
  你可以试着玩 shallow cloning 但这是非常不现实的。

使用第二个存储库,比如 Nexus ,用于存储这些罐子,并且仅引用 txt 文件(或 pom.xml 文件供 Maven 项目)以获取正确的JAR版本。
人工制品回购更适合于 distribution and release management purpose .

所有的话,如果你 必须 将jar存储在git repo中,我首先建议将它们存储在压缩格式中(这是jar的默认格式:请参见 Creating a JAR File )
压缩格式和未压缩格式都将被Git视为二进制格式,但至少在压缩格式中,克隆和签出所需的时间更少。

然而,许多线程提到了 store jar in uncompressed format :

我用的是一些能让普通的50MB tarballs进入它们的回购。
我说服他们不要压缩tarballs,而git在他们之间做delta压缩做得相当不错(尽管这样做需要相当多的RAM)。

你有更多的 deltified object on Git here :

• 如果您处理的是二进制或文本,则不会有什么不同;
• 增量不一定与以前版本中的相同路径相反,因此即使添加到历史记录中的新文件也可以以取消标识的形式存储;
• 当使用存储在Deltified表示中的对象时,与在压缩的基本表示中使用相同的对象相比,它将产生更多的成本。Deltification机制在考虑成本和空间效率的情况下进行权衡。

因此,如果克隆和签出不是每5分钟执行一次的常见操作,那么以Git的未压缩格式存储JAR将更有意义,因为:

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

建议:未压缩 .

您可以使用类似的解决方案,如 "Uncompress OpenOffice files for better storage in version control" 所以这里的问题,就是用 清洁/污损 gitattribute 使用 再拉链 作为要存储的筛选器 *.jar 文件未压缩。

.jar 文件已经被(可以)压缩了,第二次压缩可能不会产生预期的大小改进。