Bewährte Verfahren zur Speicherung von .jar-Dateien in VCS (SVN, Git, ...)

Question

Ich weiß, dass es in der Zeit von Maven nicht empfohlen wird, Bibliotheken im VCS zu speichern, aber manchmal macht es trotzdem Sinn.

Meine Frage ist, wie man sie am besten speichert - komprimiert oder unkomprimiert? Unkomprimiert sind sie größer, aber wenn sie ein paar Mal durch neuere ersetzt werden, könnte der Unterschied zwischen zwei unkomprimierten .jar-Dateien viel kleiner sein als der Unterschied zwischen komprimierten Dateien. Hat jemand ein paar Tests gemacht?

Answer 1

Beste Praxis für die Speicherung von .jar-Dateien in VCS (SVN, Git, ): nicht.

Dies könnte in einem CVCS (Centralized VCS) wie SVN, das Millionen von Dateien unabhängig von ihrer Größe verarbeiten kann, sinnvoll sein.

In einem DVCS, besonders in einem wie Git, ist das nicht der Fall (und seine Grenzen ):

• Binäre Dateien passen nicht gut zu VCS .
• Das Klonen eines DVCS-Repositoriums führt standardmäßig dazu, dass Sie alle seiner Geschichte, mit allen Versionen der Gläser.
  Das ist langsam und braucht viel Speicherplatz, egal wie gut die Jars komprimiert sind.
  Sie könnten versuchen, mit oberflächliches Klonen aber das ist höchst unpraktisch.

Verwenden Sie ein zweites Repository, wie Nexus für die Speicherung dieser Gefäße, und verweisen nur auf eine txt Datei (oder eine pom.xml Datei für Maven Projekt), um die richtigen Jar-Versionen zu holen.
Ein Artefakt-Repositorium ist besser geeignet für Verteilung und Freigabemanagement .

---

Trotzdem, wenn Sie muss jar in einem Git-Repo zu speichern, hätte ich empfohlen, sie zunächst in ihrem komprimierten Format zu speichern (was das Standardformat für ein jar ist: siehe Erstellen einer JAR-Datei )
Sowohl das komprimierte als auch das unkomprimierte Format würde von Git als binär behandelt werden, aber zumindest würde das Klonen und Auschecken in einem komprimierten Format weniger Zeit in Anspruch nehmen.

In vielen Threads wird jedoch die Möglichkeit erwähnt, die jar im unkomprimierten Format speichern :

Ich verwende einige Repos, in die regelmäßig 50-MB-Tarballs eingecheckt werden.
Ich habe sie davon überzeugt, die Tarballs nicht zu komprimieren, und Git macht eine ziemlich gute Arbeit bei der Delta-Komprimierung zwischen ihnen (obwohl es dafür ziemlich viel RAM braucht).

Sie haben mehr über deltified Objekt auf Git hier :

• Es macht keinen Unterschied, ob es sich um binäre oder um Textdaten handelt;
• Das Delta bezieht sich nicht notwendigerweise auf denselben Pfad in der vorherigen Revision, so dass sogar eine neue Datei, die der Historie hinzugefügt wurde, in einer delitierten Form gespeichert werden kann;
• Die Verwendung eines Objekts, das in der deltifizierten Darstellung gespeichert ist, würde mehr Kosten verursachen als die Verwendung desselben Objekts in der komprimierten Basisdarstellung. Der Deltifizierungsmechanismus stellt einen Kompromiss dar, bei dem diese Kosten sowie die Raumeffizienz berücksichtigt werden.

Wenn also Klonen und Auschecken keine üblichen Vorgänge sind, die Sie alle 5 Minuten durchführen müssen, ist es sinnvoller, die Jar-Datei in einem unkomprimierten Format in Git zu speichern, denn:

• Git würde das Delta für diese Dateien komprimieren/berechnen
• Sie hätten dann unkomprimierte jar-Dateien in Ihrem Arbeitsverzeichnis, die dann möglicherweise schneller geladen werden könnten.

Empfehlung: unkomprimiert .

Answer 2

Sie können eine ähnliche Lösung verwenden, wie sie in den Antworten auf "Entkomprimieren von OpenOffice-Dateien zur besseren Speicherung in der Versionskontrolle" Frage hier auf SO, nämlich die Verwendung von reinigen / verschmieren Git-Attribut mit rezipieren als Filter zum Speichern *.jar Dateien unkomprimiert.

Answer 3

.jar Dateien bereits komprimiert sind (sein können), wird eine zweite Komprimierung wahrscheinlich nicht die erwartete Größenverbesserung bringen.