Best practice for storing .jar files in VCS (SVN, Git, ...)

Question

I know that in Maven times it was not recommended to store libraries in VCS, but sometimes it makes sense.

My question is how best to store them - compressed or uncompressed? They are more uncompressed, but if you replace them a couple of times with newer ones, then, possibly, the saved difference between two uncompressed .jar files can be much less than the difference of compressed ones. Has someone done some tests?

Answer 1

Best practice for storing .jar files in VCS (SVN, Git, ...): do not.

This may make sense in CVCS (Centralized VCS), such as SVN, which can process millions of files regardless of their size.

This is not in DVCS, especially in Git style (and its limits ):

• Binary files are not VCS compliant .
• By default, cloning a DVCS repo will give you the whole story, with all versions of the jar.
  It will be slow and take up a lot of disk space, no matter how well these banks are compressed.
  You can try playing with shallow cloning , but this is very impractical.

Use a second repository, such as Nexus , to store these jars and only the a txt link (or the pom.xml file for Maven ) to get the correct jar version.
The artifact repository is more adapted for distribution and release management purposes .

---

All that said, if you should store jar in a Git repository, I would first recommend storing them in a compressed format (which is the standard format for jar: see Creating a JAR file )
Both compressed and uncompressed formats will be processed as binary using Git, but at least in compressed format, cloning and verification will take less time.

However, many threads mention the ability to store the jar in an uncompressed format :

I use some repositories that deposit regular 50 MB file cabinets into them.
I convinced them not to compress tarballs, and Git does a pretty decent job of delta compression between them (although it requires quite a lot of RAM).

You have another definable object on Git here :

• It doesn’t matter if you are dealing with binary or text text;
• The delta does not necessarily refer to the same path in the previous edition, so even a new file added to the history can be stored in isolated form;
• When using an object stored in a defined view, it will cost more than using the same object in a compressed base view. The division mechanism includes a compromise that takes into account this cost, as well as the efficiency of space use.

So, if clones and checks are not normal operations that you have to do every 5 minutes, saving jar in uncompressed format in Git makes sense, because:

• Git will compress / calculate delta for these files
• In your working directory, you will get an uncompressed jar, which can then be loaded faster.

Recommendation: uncompressed .

Answer 2

You can use a similar solution found in the answers to “Uncompress OpenOffice files for better storage in version control” here on SO, namely using clean / smudge gitattribute with rezip as a filter for storing *.jar uncompressed files.

Answer 3

.jar files (can be) compressed, compressing them a second time will probably not give the expected size improvement.