Procedura consigliata per archiviare file .jar in VCS (SVN, Git, …)

Lo so, al tempo di Maven non è consigliabile memorizzare le librerie in VCS, ma a volte ha senso, però.

La mia domanda è come conservarli 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?

Procedura consigliata per archiviare 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 è in un DVCS, specialmente in uno come Git (e nei suoi limiti ):

  • I file binari non si adattano bene a VCS .
  • Per impostazione predefinita, la clonazione di un repository DVCS ti consente di ottenere tutta la cronologia, con tutte le versioni jar.
    Ciò sarà lento e richiederà molto spazio su disco, non importa quanto bene quei vasi siano compressi.
    Potresti provare a giocare con la clonazione superficiale , ma questo è altamente poco pratico.

Usa un secondo repository, come Nexus , per archiviare quei vasi e pom.xml riferimento solo a un file txt (o un file pom.xml per il progetto Maven ) per recuperare le giuste versioni jar.
Un repository di elementi è più adatto per la distribuzione e lo scopo di gestione del rilascio .


Detto questo, se devi memorizzare jar in un repository Git, ti consiglio inizialmente di memorizzarli nel loro formato compresso (che è il formato predefinito per un jar: vedi Creazione di un file JAR )
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 menzionano la possibilità di memorizzare jar in formato non compresso :

Sto usando alcuni repository che ricevono regolarmente tarball da 50MB in loro possesso.
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ù oggetti object di delega su Git qui :

  • Non fa differenza se hai a che fare con binari o testo;
  • Il delta non è necessariamente contro lo stesso percorso nella revisione precedente, quindi anche un nuovo file aggiunto alla cronologia può essere memorizzato in una forma delitificata;
  • Quando viene utilizzato un object archiviato nella rappresentazione delificata, ciò comporterebbe un costo maggiore rispetto all’utilizzo dello stesso object nella rappresentazione base compressa. Il meccanismo di delimitazione fa un compromesso tenendo conto di questo costo, nonché dell’efficienza dello spazio.

Quindi, se cloni e casse non sono operazioni comuni che dovresti eseguire ogni 5 minuti, la memorizzazione di jar in un formato non compresso in Git avrebbe più senso perché:

  • Git avrebbe compresso / computo delta per quei file
  • Si finirebbe con jar non compressi nella directory di lavoro, jar che potrebbero quindi essere caricati più velocemente.

Raccomandazione: non compressa .

È ansible utilizzare la soluzione simile trovata nelle risposte alla domanda ” Decomprimi i file di OpenOffice per una migliore archiviazione in controllo versione” qui su SO, ovvero usando gitattribute clean / smudge usando rezip come filtro per memorizzare i file *.jar non compressi.

.jar file .jar sono (possono essere) compressi già, comprimendoli una seconda volta probabilmente non produrranno il miglioramento delle dimensioni che ci si aspetta.