Uso de Subversion como repositorio de artefactos frente a una herramienta específica de administración de artefactos

TL; DR: ¿Por qué usar algo como Apache Archiva o Sonatype Nexus como repositorio de artefactos en lugar de Subversion?

El sistema de compilación que uso actualmente tiene muchos blobs binarios (imágenes, archivos de sonido, binarios compilados, etc.), tanto como entrada como salida para nuestras compilaciones. Nuestro sistema para gestionarlos es muy ad hoc; algunos se registran en nuestro repositorio de Subversion junto con nuestro código, algunos se almacenan en otro lugar fuera de cualquier control de versión formal.

Estoy buscando consolidar esto, por lo que tenemos algo que es más coherente y fácil de usar, y que separa los artefactos binarios del código.

Google me dice que hay una selección de repositorios de artefactos disponibles ( Archiva , Nexus , Artifactory , ...), pero al leer, no veo ninguna ventaja al usarlos sobre Subversion. Eso se encargará de los binarios para nosotros; ya lo hace para algunos de nuestros binarios, solo queremos reorganizar el diseño del repositorio para separarlos del código, y tiene la notable ventaja de que ya tenemos servidores y experiencia en Subversion.

Entonces. ¿Cuál es la ventaja de usar un sistema de administración de artefactos dedicado sobre el uso de una herramienta de control de versión general como Subversion?

svn dependency-management

— yo y
fuente

¡Con mucho, la mayor ventaja de usar una herramienta dedicada es que otras herramientas saben cómo manejarlas ! Pueden colocar artefactos en esas herramientas y pueden retirarlos de manera automatizada.

— Joachim Sauer

ver también: programmers.stackexchange.com/questions/261751/…

— anfibio

Respuestas:

Respuesta corta: en general, no necesita un historial de artefactos binarios y cambios en esos artefactos, solo necesita versiones específicas.

Respuesta más larga: cada vez que realiza un pequeño cambio en un archivo binario, los sistemas de control de versiones no tienen forma de crear un delta, una diferencia entre los dos archivos, por lo que crea una copia completamente nueva.

En un CVCS, como SVN, eso no es un gran problema, porque solo tiene una copia central de su repositorio: su copia local es solo una versión. (Aunque, incluso entonces, su repositorio puede volverse muy grande, haciendo que los registros sean más lentos). Pero, ¿qué sucede si luego cambia a un DVCS, donde cada copia de un repositorio tiene el historial completo de cada archivo? El tamaño de los cambios se vuelve muy relevante allí.

¿Y qué te da a cambio del dolor? Lo único que ofrece es poder volver a una versión anterior de su repositorio y saber que tiene los binarios correctos para esa versión.

¿Pero necesitas todo el binario en tu repositorio para hacer eso? ¿O puede salirse con la suya simplemente teniendo un archivo de texto, diciéndole al proceso de compilación qué versiones extraer de otro repositorio en otro lugar?

Esto último es lo que ofrecen los repositorios de artefactos en general.

Además, algunos de los más profesionales, como Nexus, también le darán información sobre la licencia de artefactos de terceros, para que no corra el riesgo de caer en alguna cláusula sutil en lo que cree que es una biblioteca FOSS.

— pdr
fuente

Ok, debería evitar usar mi repositorio actual de Subversion como un repositorio de artefactos, pero ¿por qué no configurar un nuevo repositorio de Subversion? Eso parece tener las mismas ventajas y desventajas; un repositorio de artefactos presumiblemente tendría los mismos problemas sobre el almacenamiento de datos binarios grandes.

— yo_y el

@me_and: Usted podría hacer eso. Pero luego debe administrar qué revisión proporciona qué versión del artefacto. ¿Por qué dedicar ese trabajo extra cuando un repositorio de artefactos lo hace por usted? Es como decir "¿Entonces podría usar el Bloc de notas para escribir mi código? ¿Por qué molestarse con Eclipse entonces?" Además, nunca podrá eliminar versiones antiguas para ahorrar espacio. Puedes hacerlo con un repositorio de artefactos.

— pdr

Para enfatizar y extender la respuesta de @pdr, si usara svn como un repositorio de artefactos binarios, es probable que tenga problemas de almacenamiento porque svn está diseñado para no eliminar datos nunca. En un lugar donde trabajé, usamos svn para el almacenamiento de artefactos, y regularmente excedimos los límites de almacenamiento porque era difícil (no imposible, pero complicado) eliminar los artefactos viejos no utilizados de la tienda. Las herramientas de repositorios binarios nativos como Artifactory y Nexus permiten la eliminación de artefactos innecesarios.

— Matthew Skelton

Corrección: Subversion usa deltas binarios internamente (y AFAIK solo esos). Hice experimentos hace muchos años con el almacenamiento de archivos de MS Office y fue extremadamente efectivo. El tamaño del repositorio creció muy lentamente, incluso cuando se reorganizaron 200 diapositivas de PowerPoint. Pero la efectividad del algoritmo binario delta variará mucho según el tipo de archivo y creo que la falta de política de retención es el verdadero problema aquí (algo que podría solucionar con un volcado / carga filtrado, pero luego comienza a escribir su propia solución).

— Peter Becker

"los sistemas de control de versiones no tienen forma de crear un delta", el problema es que hacen exactamente eso, desde 2006 ... subversion.apache.org/docs/release-notes/1.4.html#svndiff1 en.wikipedia. org / wiki / Xdelta

— RnR

Usamos SVN como repositorio para versiones de lanzamiento y funciona muy bien. Tenemos en un repositorio de lanzamiento mejor que 30 gb de varias compilaciones de lanzamiento y funciona bien sacando compilaciones para su implementación.

Algunas de las ventajas de hacer esto son ...

Los archivos binarios agregados a SVN se comprimen casi en un 60-70 por ciento en promedio de ahorro de espacio.
SVN sirve como una biblioteca (artefacto) para lanzamientos y el repositorio está respaldado para fines de recuperación de desastres.
SVN a través de https permite la entrega segura de código de liberación en una DMZ.

— Lance Lyons
fuente