Best practice per archiviare file .jar in VCS (SVN, Git, ...)

Question

Lo so, nel periodo di Maven non è consigliabile archiviare le librerie in VCS, ma a volte ha senso, però.

La mia domanda è come memorizzarli al meglio - compressi o non compressi? Non compressi sono più grandi, ma se vengono sostituiti un paio di volte con quelli nuovi, allora forse la differenza memorizzata tra due file .jar non compressi potrebbe essere molto più piccola della differenza tra quelli compressi. Qualcuno ha fatto dei test?

Answer 1

Best practice per memorizzare file .jar in VCS (SVN, Git, ...): no.

Potrebbe avere senso in un CVCS (VCS centralizzato) come SVN, che può gestire milioni di file qualunque sia la loro dimensione.

Non fa in un DVCS, soprattutto uno come Git (e its limits):

• file binari don't fit well with VCS.
• Per impostazione predefinita, la clonazione di un repository DVCS consente di ottenere tutte le della sua cronologia, con tutte le versioni jar.
  Questo sarà lento e richiederà molto spazio su disco, non importa quanto bene quei vasi siano compressi.
  Si potrebbe provare a giocare con shallow cloning, ma questo è altamente poco pratico.

utilizzare un secondo repository, come Nexus, per la memorizzazione di tali barattoli, e di riferimento un file txt (o un file pom.xml per Maven progetto) al fine di recuperare le versioni jar destra.
Un repository artefatto è più adatto per distribution and release management purpose.

---

Detto questo, se si must negozio vaso in un repo Git, avrei dovuto raccomandare inizialmente per memorizzarli nel loro formato compresso (che è il formato predefinito per un barattolo: vedi Creating a JAR File)
Sia il formato compresso che quello non compresso sarebbero trattati come binari da Git, ma almeno, in un formato compresso, il clone e il checkout richiederebbero meno tempo.

Tuttavia, molti thread menziona la possibilità di store jar in uncompressed format:

sto utilizzando alcuni pronti contro termine che ottenere regolari tarball 50MB controllato in loro.
Li ho convinti a non comprimere i tarball, e git fa un discreto lavoro di compressione delta tra di loro (anche se ha bisogno di un bel po 'di RAM per farlo).

Hai più su deltified object on Git here:

• Non fa differenza se si tratta di binario o di testo;
• Il delta non è necessariamente sullo stesso percorso della revisione precedente, quindi anche un nuovo file aggiunto alla cronologia può essere memorizzato in una forma delitificata;
• Quando viene utilizzato un oggetto memorizzato nella rappresentazione delta, esso comporta un costo maggiore rispetto all'utilizzo dello stesso oggetto nella rappresentazione base compressa. Il meccanismo di delimitazione fa un compromesso tenendo conto di questo costo, nonché dell'efficienza dello spazio.

Quindi, se i cloni e le casse sono operazioni non comuni che si dovrebbe eseguire ogni 5 minuti, stoccaggio vaso in un formato non compresso in Git avrebbe più senso perché:

• Git sarebbe delta compresso/computo per quei file
• Si finirebbe con il jar non compresso nella directory di lavoro, i jar che potrebbero quindi essere caricati più rapidamente.

Raccomandazione: non compresso.

Answer 2

.jar I file sono (possono essere) compressi già, la loro compressione una seconda volta probabilmente non produrrà il miglioramento delle dimensioni che ci si aspetta.

Answer 3

È possibile utilizzare una soluzione simile a quella trovata in risposte a "Uncompress OpenOffice files for better storage in version control" domanda qui su SO, vale a dire utilizzando pulito/sbavaturegitattribute utilizzando rezip come filtro per memorizzare *.jar file non compressi.