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

Question

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

#1 da (13 voti)
#2 da (0 voti)

18

TL; DR: Perché usare qualcosa come Apache Archiva o Sonatype Nexus come repository artefatto al posto di Subversion?

Il sistema di build che uso al momento ha molti blob binari (immagini, file audio, binari compilati, ecc.), sia come input sia come output delle nostre build. Il nostro sistema per gestirli è molto ad hoc; alcuni sono controllati nel nostro repository Subversion insieme al nostro codice, alcuni sono memorizzati altrove al di fuori di qualsiasi controllo di versione formale.

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

Google mi dice che è disponibile una selezione di repository di artefatti ( Archiva , Nexus , Artifactory , ...), ma dalla lettura in giro, I non vedo alcun vantaggio nell'utilizzare questi su Subversion. Ci occuperemo di noi per i binari - lo fa già per alcuni dei nostri binari, vorremmo solo riorganizzare il layout del repository per separarli dal codice - e ha il notevole vantaggio che abbiamo già server e competenze Subversion.

. Qual è il vantaggio dell'utilizzo di un sistema di gestione degli artefatti dedicato rispetto all'utilizzo di uno strumento di controllo della versione generale come Subversion?

svn dependency-management

posta me_and 22.01.2013 - 19:00

fonte

2 risposte

0

Usiamo SVN come repository per build di release e lo fa molto bene. Abbiamo un repository di release migliore di 30 GB di varie versioni di release e offre un buon rendimento estrapolato per la distribuzione.

alcuni dei vantaggi di farlo sono ..

I binari aggiunti a SVN sono compressi di circa il 60-70 percento in avg di spazio di salvataggio.
SVN funge da libreria (artefice) per le versioni e il repository viene sottoposto a backup ai fini del ripristino di emergenza.
SVN via https consente la consegna sicura del codice di rilascio in una DMZ.

risposta data 24.09.2015 - 19:06

fonte

Leggi altre domande sui tag svn dependency-management

Il modo migliore per strutturare un repository Git per Maven qual è la differenza tra callback e ascoltatori?

score 13 · Accepted Answer

Risposta breve: in genere, non è necessaria una cronologia di risorse utente binarie e modifiche a tali risorse, sono necessarie solo versioni specifiche.

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

In un CVCS, come SVN, non è un grosso problema, perché hai solo una copia centrale del tuo repository - la tua copia locale è solo una versione. (Anche se, anche allora, il repository può diventare molto grande, rendendo più lento il check-in.) Ma cosa succede se in seguito si passa a un DVCS, in cui 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 è poter tornare a una versione precedente del tuo repository e sapere che hai i binari corretti per quella versione.

Ma hai bisogno dell'intero binario nel tuo repository per farlo? O 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 offerto dai repository di artefatti in generale.

Inoltre, alcuni dei più professionali, come Nexus, ti daranno anche informazioni sulle licenze per gli artefatti di terze parti, in modo da non rischiare di cadere in qualche clausola sottile in ciò che ritieni essere un Libreria FOSS.