Utilizzo di Subversion come repository di artefatti rispetto a uno specifico strumento di gestione degli artefatti

TL; DR: Perché usare qualcosa come Apache Archiva o Sonatype Nexus come repository di artefatti anziché Subversion?

Il sistema di compilazione che uso attualmente ha molti BLOB binari (immagini, file audio, binari compilati, ecc.), Sia come input che come output per i nostri build. Il nostro sistema di gestione di questi è molto ad hoc; alcuni sono controllati nel nostro repository Subversion insieme al nostro codice, altri sono archiviati altrove al di fuori di qualsiasi controllo formale della versione.

Sto cercando di consolidare questo, quindi abbiamo qualcosa che è più autoconsistente e facile da usare e che separa gli artefatti binari dal codice.

Google mi dice che ci sono una selezione di repository di artefatti disponibili ( Archiva , Nexus , Artifactory , ...), ma dalla lettura in giro, non riesco a vedere alcun vantaggio nell'usarli su Subversion. Ci occuperemo dei binari per noi - lo fa già per alcuni dei nostri binari, vorremmo solo riorganizzare il layout del repository per separarli dal codice - e ha il notevole vantaggio di disporre già di server e competenze Subversion.

Così. Qual è il vantaggio di utilizzare un sistema di gestione degli artefatti dedicato rispetto a uno strumento di controllo della versione generale come Subversion?

svn dependency-management

— io e
fonte

Di gran lunga il più grande vantaggio dell'utilizzo di uno strumento dedicato è che altri strumenti sanno come gestirli ! Possono mettere gli artefatti in quegli strumenti e possono portarli indietro in modo automatizzato.

— Joachim Sauer,

vedi anche: programmers.stackexchange.com/questions/261751/…

— anfibio

Risposte:

Risposta breve: in genere, non è necessaria una cronologia di artefatti binari e modifiche a tali artefatti, ma solo versioni specifiche.

Risposta più lunga: ogni volta che si commette una piccola modifica in un file binario, i sistemi di controllo della versione non hanno alcun modo di creare un delta - una differenza tra i due file - quindi crea una copia completamente nuova.

In un CVCS, come SVN, non è un gran problema, perché hai solo una copia centrale del tuo repository: la tua copia locale è solo una versione. (Anche se, anche in questo caso, il tuo repository può diventare molto grande, rendendo i checkin più lenti.) Ma cosa succede se in seguito passi a un DVCS, dove ogni copia di un repository ha la cronologia completa di ogni file? La dimensione delle modifiche diventa molto rilevante lì.

E cosa ti dà in cambio del dolore? L'unica cosa che offre è la possibilità di tornare a una versione precedente del repository e sapere di avere i binari corretti per quella versione.

Ma hai bisogno dell'intero binario nel tuo repository per farlo? Oppure puoi cavartela semplicemente con un file di testo, dicendo al processo di compilazione quali versioni estrarre da un altro repository altrove?

Quest'ultimo è ciò che viene generalmente offerto dai repository di artefatti.

Inoltre, alcuni di quelli più professionali, come Nexus, ti forniranno anche informazioni sulla licenza per manufatti di terze parti, in modo da non rischiare di cadere in qualche sottile clausola in ciò che ritieni sia una biblioteca FOSS.

— pdr
fonte

Ok, dovrei evitare di usare il mio repository Subversion corrente come repository di artefatti, ma perché non impostare un nuovo repository Subversion? Ciò sembra avere tutti gli stessi vantaggi e svantaggi; un repository di artefatti avrebbe presumibilmente gli stessi problemi relativi alla memorizzazione di dati binari di grandi dimensioni.

— io_e il

@me_and: potresti farlo. Ma poi devi gestire quale revisione fornisce quale versione del manufatto. Perché darti quel lavoro extra quando un repository di artefatti lo fa per te? È come dire "Quindi potrei usare Notepad per scrivere il mio codice? Perché preoccuparsi di Eclipse allora?" Inoltre, non sarai mai in grado di rimuovere veramente le vecchie versioni per risparmiare spazio. È possibile con un repository di artefatti.

— PDR

Per enfatizzare ed estendere la risposta di @pdr, se dovessi usare svn come repository di artefatti binari, probabilmente incontrerai problemi di archiviazione perché svn è progettato per non eliminare mai i dati. In un posto in cui ho lavorato, abbiamo usato svn per la memorizzazione degli artefatti e abbiamo regolarmente superato i limiti di archiviazione perché era difficile (non impossibile, ma difficile) rimuovere i vecchi manufatti inutilizzati dal negozio. Strumenti di repository binari nativi come Artifactory e Nexus consentono la cancellazione di artefatti non necessari.

— Matthew Skelton,

Correzione: Subversion utilizza delta binari internamente (e solo quelli AFAIK). Ho fatto molti anni fa esperimenti con l'archiviazione di file MS Office ed è stato estremamente efficace. Le dimensioni del repository sono cresciute molto lentamente, anche quando sono state rimescolate pesantemente 200 diapositive di PowerPoint. Ma l'efficacia dell'algoritmo delta binario varierà notevolmente in base al tipo di file e penso che la mancanza di criteri di conservazione sia il vero problema qui (qualcosa che potresti aggirare con un dump / caricamento filtrato, ma poi inizi a scrivere la tua soluzione).

— Peter Becker,

"i sistemi di controllo versione non hanno alcun modo di creare un delta" - il problema è che fanno esattamente questo - dal 2006 ... subversion.apache.org/docs/release-notes/1.4.html#svndiff1 en.wikipedia. org / wiki / Xdelta

— RnR,

Usiamo SVN come repository per build di rilascio e funziona molto bene. Abbiamo in un repository di versioni migliori di 30 gb di varie build di release e funziona bene estraendo build per la distribuzione.

alcuni dei vantaggi di fare questo sono ...

I file binari aggiunti a SVN sono compressi quasi al 60-70 percento in media con un risparmio di spazio.
SVN funge da libreria (artificiale) per le versioni e viene eseguito il backup del repository per scopi di Disaster Recovery.
SVN tramite https consente la consegna sicura del codice di rilascio in una DMZ.

— Lance Lyons
fonte