x64 tortoise subversion para net manager cliente svn version-control binary

subversion - tortoise>- svn



¿Es aceptable/bueno almacenar binarios en SVN? (15)

Nos gustaría compartir archivos binarios del proyecto en tiempo de ejecución. Entonces, cada miembro del equipo podría tomar la versión de trabajo actual. ¿Es aceptable / bueno almacenar binarios en tiempo de ejecución en el SVN?

Al menos almaceno los binarios en el SVN, de esta manera puedo volver rápidamente al binario de la versión particular y ver si el error estaba sucediendo o no y rastrear la versión, donde se introdujo el error, en lugar de verificar todo el proyecto , configure todos los ajustes relacionados con el proyecto y el entorno, y luego compílelo.

Almacene binarios que no todos pueden construir. Diseño chips en Verilog y VHDL y el equipo de software no tiene esas herramientas. Entonces almacenamos los binarios de salida en SCM.

Cada vez que veo una biblioteca en un directorio de Subversion, hago las siguientes preguntas:

  • ¿Qué versión es? (generalmente tienes axis.jar y no axis-1.4.jar )
  • ¿por qué estaba incluido? (especialmente complicado con dependencias de dependencias)

Si no tiene un sistema de administración de dependencias, normalmente no puede responder ambas preguntas. Y es el primer paso para Jar Hell.

Puedo recomendar Apache Ivy (otro puede jurar por Maven) con un repositorio de intranet. Usando Ivy, nunca tuve que almacenar bibliotecas en SVN y siempre pude responder a las preguntas mencionadas anteriormente.

Como muchos ya lo han dicho, es aceptable.

Sí, es conveniente tener todo a mano desde una ubicación, desde donde puede (por ejemplo) pagar una etiqueta anterior que ya esté en formato binario con sus dependencias correctas.

Pero NO es bueno, especialmente con fines de copia de seguridad. Almacenamos todos nuestros binarios (y parte de las dependencias) en SVN y a medida que crecía el proyecto, de modo que la sección binaria sí lo hizo.

Desafortunadamente, svnadmin dump solo descarga todo, no puedes especificar una ruta del repositorio para excluir. Por lo tanto, las copias de seguridad (y las actualizaciones del servidor svn) se volvieron muy dolorosas.

Si agrega que después de un tiempo no tan largo en nuestro caso esos binarios ya no son útiles, estoy seguro de que no volveré a hacerlo en un caso similar (pero lo haría en un proyecto más pequeño).

Así que recomendaría pensar dos veces antes de hacer eso y tratar de pronosticar qué tan grande puede crecer y qué más puede pasar.

Diría que si facilita la vida de tu equipo, entonces hazlo. Si disminuye el tiempo necesario para configurar un entorno de desarrollo en funcionamiento, apúntelo.

Está perfectamente bien y es aceptable almacenar binarios en el repositorio de SVN. Como nota al margen, no veo por qué alguien querría almacenar artefactos de construcción en el repositorio (no digo que hagas eso).

Hay cierta controversia sobre este asunto, pero digo que sí.

Las dos razones más comunes por las que desea almacenar binarios en un Sistema de control de versiones son (escritas en 2009):

  • almacenar bibliotecas externas de terceros .
    Por lo general, uno los almacena en un repositorio de Maven, pero almacenarlos en SVN le permite tener uno y solo un referencial para todas sus necesidades: obtener sus fuentes y obtener sus bibliotecas que necesita para compilar esas fuentes. Todo proviene de un repositorio.

(Como señaló ivorujavaboy en 2017: "La única buena razón para hacer esto en la actualidad es si tienes librerías STATIC que nunca cambiarán, lo cual es un caso realmente raro").

  • almacene las entregas para una implementación más rápida .
    Por lo general, las entregas (el ejecutable que construye para implementar en la producción) se crean a pedido.
    Pero si tiene muchos entornos de preproducción, y si tiene muchas entregas, el costo de construirlas para el ensamblaje, la integración, la homologación y las plataformas de preproducción puede ser elevado.
    Una solución es construirlos una vez, almacenarlos en una sección de entregas de su SVN, y usarlos directamente en su entorno diferente.
    Nota:
    Esto se aplica también a los elementos de desarrollo: si tiene un proceso Jaxb que genera 900 archivos POJO (mediante enlace XML) y necesita descargar ese conjunto de desarrollo en múltiples entornos, puede desear 1 transacción de copia de archivo comprimido, en lugar de 900 unidades.

Así que sí, es "aceptable / bueno almacenar binarios en tiempo de ejecución en el SVN" ... por las razones correctas.

Habiendo dicho eso:

  • Wim Coenen menciona con razón las desventajas (mala práctica, lentitud, falta de coincidencia entre las fuentes y la entrega almacenada)
  • Vladimir aboga por el uso de un referencial de entrega (Nexus o, como menciona Vladimir, Apache ivy )
  • RogerV ilustra las ventajas de usar dicho referencial de entrega (Nexus en su caso)

No para este propósito, no. Debería usar un almacén de archivos externo, como un servidor FTP o Web. De esta forma, es fácil descargar una versión particular de su binario en tiempo de ejecución sin tener que actualizar primero a esa revisión en SVN.

No, no almacene binarios al lado de su código fuente (a menos que tenga buenas razones para compensar las desventajas).

Desventajas:

  • fomenta las malas prácticas de construcción en proyectos grandes. La mejor práctica es automatizar completamente tu construcción. La comisión de binarios le permite ignorar eso: "solo haga manualmente la construcción de las partes que han cambiado" :-(
  • actualizaciones y confirmaciones más lentas
  • los commits que cambian el código fuente pero no los binarios correspondientes causarán confusión entre los desarrolladores. ¿Cómo se detecta que hay un desajuste?
  • svn update actualizará la marca de tiempo de tus binarios, confundiendo tus herramientas de compilación que erróneamente pensarán que los binarios son más nuevos que los cambios en tu código fuente.
  • causa conflictos espurios en los binarios para la svn update svn merge y svn merge
  • usa más espacio de disco en el repositorio. (Esto puede ser insignificante según su proyecto).

En general, evite comprometer todo lo que se genere automáticamente de forma determinista a partir de otros recursos versionados. Sin redundancia -> ninguna oportunidad para inconsistencias.

En su lugar, use un servidor de integración continua para reconstruir automáticamente (y ejecutar las pruebas) en cada confirmación. Deje que este servidor de compilación publique los binarios en algún lugar (fuera de SVN) si es necesario.

Ahora, esto no significa que deba tomar esto como una regla absoluta o evitar todos los binarios. Por supuesto, ponga sus herramientas de compilación y binarios de código cerrado de terceros dentro de sus proyectos. Y haga excepciones cuando tenga sentido. Idealmente, un desarrollador nuevo debería poder hacer un check out e iniciar inmediatamente el script de construcción sin perder uno o dos días en configurar su entorno.

Nuestras compilaciones de archivos Java .jar eran vinculantes en sus dependencias de archivos .jar, que estábamos verificando en svn. Mucho de esto fue redundante en la práctica, pero queríamos asegurar que cada versión de la aplicación Java que produjimos tuviera precisamente las bibliotecas con las que se realizó el control de calidad.

Lo que realmente me agravó, con este enfoque fue cuando comencé a hacer conexiones remotas al repositorio y a la sincronización. Llevaría una eternidad batir todas las bibliotecas binarias.

Desde entonces hemos abandonado esa práctica y ahora usamos Maven para administrar las dependencias de la biblioteca, incluso para proyectos que aún estamos desarrollando con la hormiga. No se verifican más binarios en svn. La vida es mucho mejor en varios frentes debido a este cambio de estrategia. Y tenemos el control riguroso de las versiones de las dependencias de la biblioteca que deseamos.

Para nuestras compilaciones de .NET, uno de mis desarrolladores ha ideado una solución que funciona en gran parte como Maven con respecto a todo lo relacionado con la administración de dependencias, y está logrando el mismo beneficio allí también.

Permitiría que mi sistema de compilación y de integración continua maneje la última versión de trabajo de las cosas, copiándolos automáticamente en un FTP, web o archivo compartido para facilitar el acceso.

Incluso mejor invertiría en un sistema de CI que maneja automáticamente artefactos de construcción, me encanta TeamCity de jetbrains, pero hay otros. De esta forma puede manejarlo de manera completamente automática.

Sí, guárdalo.

Solíamos almacenar los binarios que entregamos a los clientes en el repositorio de SVN para hacer un seguimiento de ellos.

También otro uso de almacenar los binarios en SVN (o control de fuente) es si está proporcionando algunos módulos de utilidad interna a otros equipos en su empresa que no desean construir su proyecto para guardar su tiempo de construcción. Yo creo que es una práctica común.

Pero nunca permitimos almacenar archivos .classpath y .project de Eclipse (configuraciones relacionadas con el espacio de trabajo).

Si está desarrollando en Java, puede configurar un repositorio local y luego usar una herramienta como maven o ivy + ant para acceder a ella.

Puede cargar las actualizaciones de sus artefactos de construcción locales a su repositorio local, ya que están listos para que otros en la compañía los utilicen.

Para otros entornos de desarrollo, no sé qué herramientas similares a las anteriores están disponibles. He tendido a simplemente ponerlas en SVN y terminar con ellas.

Usualmente utilizo un repositorio separado para almacenar bibliotecas de terceros para mantenerlas fuera de los repositorios de desarrollo regulares, y hacer que mis archivos de compilación los carguen en una ubicación esperada relativa a la carpeta base del proyecto.

En realidad, uso dos repositorios. Uno para los archivos mínimos que necesito para construir mis proyectos (por ejemplo, archivos jar, lib) y otro para todo el paquete de terceros (incluida la fuente, la documentación o lo que sea) que generalmente almaceno tar.bz2.

De esta forma, si solo quieres obtener el mínimo que necesitas para construir cosas, tomas el primer repositorio, y si necesitas descubrir qué está pasando o cómo usar un paquete de terceros, puedes comenzar a tirar cosas fuera del segundo repositorio.

No es la solución ideal, pero funciona bastante bien.

Here hay más información sobre cómo svn maneja los archivos binarios.