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?¿Es aceptable/bueno almacenar binarios en SVN?
Es perfectamente aceptable y 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).
Existe cierta controversia sobre este asunto, pero digo que sí.
Diría que si facilita la vida de su equipo, hágalo. Si disminuye el tiempo necesario para configurar un entorno de desarrollo en funcionamiento, apúntelo.
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.
Las dos razones más comunes que usted puede desear para almacenar binarios en un sistema de control de versiones son (escrito en 2009):
(Como se ha señalado por ivorujavaboy en 2017: "La única buena razón para hacer esto en nuestros días es si usted tiene bibliotecas estáticas que nunca va a cambiar, que es un caso muy raro")
Así que sí, es "aceptable/bueno almacenar binarios de tiempo de ejecución en el SVN" ... por las razones correctas.
Dicho esto:
Además, si no puede usar Maven o prefiere una hormiga, entonces tiene sentido almacenar las bibliotecas en su repositorio donde puedan ser fácilmente revisadas para una compilación de ant. – fluffels
@fluffels: de acuerdo. – VonC
una tercera razón común es para almacenar gráficos de mapas de bits, audio y video. Estos necesitan ser controlados por la versión también. Algunas versiones del mismo video solo pueden ser apropiadas para una determinada versión del código fuente que lo utiliza. – therobyouknow
Sí, guárdelo.
Solíamos almacenar los archivos binarios que entregamos a los clientes en el repositorio SVN para realizar un seguimiento de ello.
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).
"Pero nunca permitimos almacenar archivos .classpath y .project de Eclipse (ajustes relacionados con el espacio de trabajo).": Argh! Demasiado. Creo que puede ser útil;) Ver http://stackoverflow.com/questions/337304 – VonC
Y http://stackoverflow.com/questions/116121#119377, y http://stackoverflow.com/questions/300328 – VonC
@ VonC: gracias por los enlaces, tus respuestas son interesantes. Todavía preferiría mantener la mayoría de estos archivos fuera del control de código fuente, principalmente en un wiki. Pero lo pensaré :) – Srikanth
Permitiría que mi sistema de integración continua maneje la última versión de trabajo de las cosas, copiándolas automáticamente en un FTP, web o archivo compartido para facilitar el acceso.
Aún mejor, invertiría en un sistema de CI que maneja automáticamente artefactos de construcción, me encanta TeamCity de los cerebros del yo mismo, pero hay otros. De esta forma puede manejarlo de manera completamente automática.
El almacenamiento de archivos binarios bajo el control de la versión quizás esté derrotando el propósito del control de versiones. Es mejor utilizar HTTP/FTP ... ¡Esta discusión sobre SO en https://stackoverflow.com/questions/104453/version-control-for-binaries puede ser útil!
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ó, sin embargo, con este enfoque fue cuando comencé a hacer conexiones remotas con el repositorio y 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 .NET, uno de mis desarrolladores ha ideado una solución que funciona en gran parte como Maven con respecto a todos los aspectos de administración de dependencias, y está logrando el mismo beneficio allí también.
Al menos guardo 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 o no y rastrear la versión, donde se introdujo el error, en lugar de verificar a cabo todo el proyecto, configure todos los entornos relacionados con el proyecto y la configuración del entorno, y luego compílelo.
si está desarrollando en Java, entonces se puede establecer un local repository y luego utilizar una herramienta como maven o ivy + ant para acceder a ella.
Puede cargar las actualizaciones de sus artefactos de construcción locales en su repositorio local, ya que están listos para que otros en la compañía los usen.
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.
Normalmente utilizo un repositorio separado para almacenar bibliotecas de terceros para mantenerlos fuera de los repositorios de desarrollo normales, 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 normalmente almaceno tar.bz2.
De esta manera, si solo quiere obtener el mínimo que necesita para construir cosas, tome el primer repositorio, y si necesita averiguar qué está pasando o cómo usar un paquete de terceros, puede comenzar a sacar cosas del segundo repositorio.
No es la solución ideal, pero funciona bastante bien.
Here es un poco más de información sobre cómo svn maneja los archivos binarios.
Cada vez que veo una biblioteca en un directorio Subversion, pido a las siguientes preguntas:
axis.jar y no axis-1.4.jar)Si no tiene un sistema de administración de dependencias, normalmente no puede responder a 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 han dicho, es aceptable.
Sí, es conveniente tener todo a mano desde una ubicación, desde donde puede (por ejemplo) pagar una etiqueta anterior ya en formato binario con sus dependencias correctas.
Pero es NO bueno, especialmente para los propósitos de reserva. 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 simplemente vuelca todo, no puede 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 prolongado en nuestro caso esos binarios ya no eran ú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.
Almacenar 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.
No, no almacene binarios al lado de su código fuente (a menos que tenga buenas razones que compensen las desventajas).
Desventajas:
svn update actualizará la marca de tiempo de los binarios, confundiendo sus herramientas de construcción que erróneamente piensan los binarios son más recientes que los cambios en el código fuente.svn update y svn mergeEn general, evite cometer 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, utilice 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.
"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". ... Supongo que la IC sacará lo que necesita del control de la fuente, entonces, ¿no estamos en una situación de huevo/gallina? –
Olvídate de ese comentario: volví a leer la pregunta y me di cuenta de que preguntaban si deberían almacenar la 'salida' de su versión en control de fuente. Lo estaba viendo (y a su respuesta) desde el contexto de '¿deberíamos almacenar dependencias binarias en el control de origen'? –
Tenemos uno o dos pequeños programas que rara vez cambian, y son un error para compilar, necesitan un entorno especializado y lo que usted necesita. Los almacenamos en SVN por simplicidad/cordura. – Evan
En realidad, ahora que lo pienso, también tenemos algunos artefactos que no se pueden construir en línea de comandos o de manera automatizada, y con frecuencia vacilamos sobre la cuestión de si vale la pena colocarlos en el repositorio (SWF <- FLA) – Evan