Utilisation de Subversion comme référentiel d'artefacts par rapport à un outil de gestion d'artefacts spécifique

TL; DR: Pourquoi utiliser quelque chose comme Apache Archiva ou Sonatype Nexus comme référentiel d'artefacts au lieu de Subversion?

Le système de build que j'utilise actuellement a beaucoup de blobs binaires (images, fichiers audio, binaires compilés, etc.), à la fois en entrée et en sortie de nos builds. Notre système de gestion est très ponctuel; certains sont archivés dans notre référentiel Subversion à côté de notre code, certains sont stockés ailleurs en dehors de tout contrôle de version formel.

Je cherche à consolider cela, nous avons donc quelque chose de plus cohérent et facile à utiliser, et qui sépare les artefacts binaires du code.

Google me dit qu'il existe une sélection de référentiels d'artefacts disponibles ( Archiva , Nexus , Artifactory ,…), mais à la lecture, je ne vois aucun avantage à les utiliser par-dessus Subversion. Cela prendra soin des binaires pour nous - cela fait déjà cela pour certains de nos binaires, nous voudrions juste réorganiser la disposition du référentiel pour les séparer du code - et a l'avantage notable que nous avons déjà des serveurs et une expertise Subversion.

Donc. Quel est l'avantage d'utiliser un système de gestion d'artefacts dédié par rapport à l'utilisation d'un outil de contrôle de version général comme Subversion?

Réponse courte: en général, vous n'avez pas besoin d'un historique des artefacts binaires et des modifications apportées à ces artefacts, vous avez juste besoin de versions spécifiques.

Réponse plus longue: chaque fois que vous effectuez une petite modification dans un fichier binaire, les systèmes de contrôle de version n'ont aucun moyen de créer un delta - un diff entre les deux fichiers - donc il crée une toute nouvelle copie.

Dans un CVCS, comme SVN, ce n'est pas si difficile, car vous n'avez qu'une seule copie centrale de votre référentiel - votre copie locale n'est qu'une seule version. (Même si, même dans ce cas, votre référentiel peut devenir très volumineux, ce qui ralentit les enregistrements.) Mais que se passe-t-il si vous passez ultérieurement à un DVCS, où chaque copie d'un référentiel a l'historique complet de chaque fichier? L'ampleur des changements y devient très pertinente.

Et que vous apporte-t-il en échange de la douleur? La seule chose qu'il offre est de pouvoir revenir à une version précédente de votre référentiel et de savoir que vous avez les bons fichiers binaires pour cette version.

Mais avez-vous besoin de tout le binaire dans votre référentiel pour le faire? Ou pouvez-vous vous contenter d'avoir simplement un fichier texte, indiquant au processus de construction les versions à extraire d'un autre référentiel ailleurs?

Ce dernier est généralement proposé par les référentiels d'artefacts.

De plus, certains des plus professionnels, tels que Nexus, vous fourniront également des informations sur l'octroi de licences pour des artefacts tiers, afin que vous ne risquiez pas de tomber sous le coup d'une clause subtile dans ce que vous pensez être une bibliothèque FOSS.

Nous utilisons SVN comme référentiel pour les builds de versions et cela fonctionne très bien. Nous avons dans un référentiel de versions mieux que 30 Go de différentes versions et il fonctionne bien en tirant les versions pour le déploiement.

certains des avantages de le faire sont ..

• Les fichiers binaires ajoutés à SVN sont compressés de près de 60 à 70% sur un espace d'économie moyen.
• SVN sert de bibliothèque (artificielle) pour les versions et le référentiel est sauvegardé à des fins de reprise après sinistre.
• SVN via https permet une livraison sécurisée du code de version dans une DMZ.