tag - Gestión de lanzamientos en SVN
tortoise svn merge branch to trunk (13)
Cuando miro en el registro de SVN, realmente me gustaría poder ver marcadores que me digan cuándo se hicieron los lanzamientos. Lo he visto en otros sistemas de control de versiones como PVCS y Perforce .
¿Se puede hacer esto en SVN? Investigué un poco y hasta ahora parece que este tipo de cosas no son compatibles.
Editar
No queremos tener que copiar nuestra fuente a una carpeta diferente para cada lanzamiento. Esto resulta en una gran cantidad de duplicación innecesaria de archivos en la máquina de desarrollo y solo nos da un registro del número de revisión de cada lanzamiento. ¡Puedo hacer eso usando un documento de texto!
Edit2
Mi objetivo es tener una vista única que me muestre la cronología de mis lanzamientos, entre los cuales puedo ver todos los cambios de código que tuvieron lugar entre cada lanzamiento. Esto hace que sea más fácil compilar notas de la versión.
Mi objetivo es tener una vista única que me muestre la cronología de mis lanzamientos, entre los cuales puedo ver todos los cambios de código que tuvieron lugar entre cada lanzamiento.
¿Has investigado el gráfico de revisión SVN de Tortoise? Si etiqueta cada versión (que, como otros señalaron, no implica la copia de archivos, ya sea en el servidor o en la estación de trabajo), entonces puede ver todas las revisiones en orden cronológico, con las etiquetas que indican las versiones reales. Puede diferir entre lanzamientos y / o troncales concentrando las dos revisiones que le interesan y seleccionando diff del menú contextual.
+1 para usar el mensaje de confirmación.
Para un proyecto, creé un usuario SVN llamado build. La máquina de compilación usó este inicio de sesión para SVN. Cada vez que la máquina / proceso de compilación realizaba una compilación, también actualizaba un archivo y el mensaje de confirmación de SVN era la versión / otro identificador de la compilación.
Luego también creamos una etiqueta para esa compilación. De esta manera en el maletero podríamos ver las construcciones cuando / donde están intercaladas con otros cambios.
Así que mi sugerencia (la forma más sencilla de hacerlo) es crear otros archivos llamados compilación (o cualquier otra cosa que desee) y anexar a eso o simplemente modificarlo en su script / proceso de compilación y luego verificarlo nuevamente / confirmarlo con el nombre de la versión de lanzamiento como el mensaje de confirmación. Sencillo. Aparecerá en sus consultas de historial.
Además, si sabe qué revisiones está comparando puede hacer una diferencia SVN y verá qué archivos han cambiado y cómo entre las dos revisiones.
No estoy seguro de su configuración total, pero alguien mencionó TortoiseSVN. Eso es definitivamente un buen comienzo. Personalmente uso Eclipse con el complemento subclipse y me permite realizar diffs en un entorno gráfico entre revisiones. Mientras tenga su proyecto, puede comparar cualquier revisión con cualquier otra revisión y, como tal, no necesita tener todo tipo de duplicación de archivos.
Además, generalmente configuramos tres directorios en cada repositorio. Ramas, Tronco y Etiquetas. Como alguien señaló, las etiquetas se usan específicamente para identificar un lanzamiento.
Aunque Subversion no proporciona administración de versiones en sí misma, las herramientas de control de versiones generalmente no tienen esta tarea. Lo que está buscando es una herramienta de gestión de actividad / problema / cambio que puede interactuar con Subversion.
Para ese fin usamos Jira en mi lugar de trabajo y lo vinculamos con Subversion. Jira proporciona una hoja de ruta y un historial de cambios que incluye problemas en cada lanzamiento. Cada uno de esos problemas tiene enlaces a los cambios en el control del código fuente. Por lo tanto, puede vincular los cambios en el código fuente con las versiones publicadas.
Creo que generalmente es mejor mantener estas dos herramientas separadas. Aunque Perforce, en particular, trata de unir los dos, lo hacen de forma simple. Hay algunas cosas, como enviar correos electrónicos a los usuarios sobre cambios en los problemas, agregar comentarios a problemas, agregar archivos adjuntos a problemas que se hacen mucho mejor en un software especializado como Jira. Por otro lado, Jira no es muy buena en el control de versiones, fusión y fuente ... que se maneja mejor en un software especializado como Subversion.
Para una divulgación completa, hay otras herramientas además de Jira como Bugzilla, Trac, IBM Rational Jazz, etc. que pueden hacer lo mismo con Subversion que Jira aunque con distintos niveles de funcionalidad.
Copiar el tronco a una ruta de etiquetas en el repositorio svn es la forma de lograr esto. Es una copia svn, por lo que no termina con duplicados de archivos en el servidor de repositorio svn. Solo tiene archivos duplicados localmente si elige comprar una ruta svn que no sea la troncal. Se compromete con esas copias de trabajo y luego regresa a la ruta de acceso svn desde la que se prestó el servicio.
Esta es esencialmente una implementación convencional específica de ramificación en svn. Eche un vistazo al libro svn en línea para más detalles.
Eche un vistazo a los temas del Libro SVN:
Etiquetas y navegación del repositorio
Las etiquetas y las ramas son "copiar al escribir", lo que significa que no hay copias adicionales en el repositorio. En general, un desarrollador individual no necesitaría tener una copia local a menos que la necesitara por algún motivo (IE se está desarrollando en una sucursal).
Si etiqueta cada versión, puede ver las etiquetas navegando por el repositorio. Los enlaces anteriores hablan directamente sobre las herramientas de línea de comandos, pero también hay herramientas de GUI como TortoiseSVN en Windows. Puede obtener historial, hacer comparaciones, etc.
Para ver los cambios realizados en un lanzamiento, simplemente mostraría un registro del tronco desde la revisión de la etiqueta que desea volver a la revisión anterior de la etiqueta +1. Parece un trabajo extra, pero es bastante simple una vez que te acostumbras.
Con nuestras herramientas de compilación, también devolvemos un archivo con cierta información de número de versión al tronco, y el comentario tiene el número de versión de la compilación. Si su código principal está en el enlace troncal, esto también puede funcionar como un marcador para lo que está en una compilación (busque entre las confirmaciones de la versión).
El marcador sería el mensaje de confirmación escrito cuando se realiza una etiqueta para el lanzamiento (una copia svn a / etiquetas). Al menos ese es el método más común utilizado.
FYI,
La copia de SVN no es una copia impresa, solo está vinculando, por lo tanto, no ocupará más espacio que los archivos modificados. Y esas versiones tomarán espacio de todos modos. Por lo tanto, crear una copia para cada lanzamiento no ocupará espacio.
Me encuentro con el mismo problema y la forma en que he tratado de solucionarlo para mi empresa es tener una carpeta ''liberar'' en el enlace troncal, esta carpeta solo contiene el ejecutable real o lo que debe ser parte de la implementación.
Creo una nueva carpeta para cada lanzamiento comenzando con ''1.0.0.0'' en la carpeta ''release'' y también etiqueto el código con el mismo nombre de carpeta de lanzamiento, es decir, 1.0.0.0 en el caso.
No estoy seguro de si es la manera correcta de hacerlo, pero resuelve mi problema para descubrir el ejecutable que he implementado.
No como tal. La forma aceptada de hacer lanzamientos en SVN es tener un directorio de "etiquetas" donde se copie el origen de su versión para cada lanzamiento en particular. Por ejemplo /tags/release-0.11 ... No hay nada que le impida jugar con el directorio de tags por accidente, de fábrica, pero a algunas personas les gusta configurar los enlaces previos a la confirmación para evitar compromisos accidentales de liberar etiquetas. .
Aquí hay un artículo decente que describe un proceso de lanzamiento en SVN.
Richard, las etiquetas son muy similares, pero me pregunto si lo que necesitas podría no ser una rama de lanzamiento dedicada.
Para esto, crea una rama del tronco desde el principio llamada algo así como ''Liberar''. Luego, trabaje en el tronco como es normal, cuando esté listo para un lanzamiento, fusione los cambios del tronco a ''Liberar''. Esta es la única forma en que debe modificar la versión.
Luego puede etiquetar desde el lanzamiento si lo desea, no es 100% necesario.
Pero lo que esto le dará es una rama que tiene un subconjunto de las revisiones del tronco. Descubra sus fechas de lanzamiento con:
svn log --stop-on-copy svn://server/project/branches/release
Esto le dará una lista de fechas de lanzamiento (con las revisiones). Para ver lo que hay en cada lanzamiento, haz lo siguiente:
svn mergeinfo --show-revs=merged "svn://server/project/trunk" "svn://server/project/branches/release"@<release revision>
También tenga en cuenta que al trabajar de esta manera, no está limitado a una versión estrictamente secuencial de todo en el enlace troncal: puede seleccionar las revisiones, excluyendo las revisiones si aún no desea publicarlas, pero que aún incluyen revisiones posteriores.
Si sigues la convención svn normal de "tags / branches / trunk" en la raíz de tu repositorio, los desarrolladores normalmente no querrían consultar todo el repositorio, solo desde el trunk hacia abajo.
Me gustaría ofrecer un enfoque diferente que debería ayudar a resolver su problema establecido: crear notas de la versión y ver las diferencias de código entre lanzamientos.
Usamos una utilidad llamada SubWCRev que viene con Tortoise SVN. Tenemos un evento posterior a la creación que toma el número de revisión de SVN y lo pega en un archivo; en el caso de los sitios web, lo ponemos en un archivo llamado version.html. Luego, en cualquier momento, puede vincular su versión (ya sea la versión actualmente en QA, Prod o cualquier otro entorno) con el número de revisión exacto en SVN. No más etiquetado, no preguntarse qué se incluye en un lanzamiento, no más molestando a los desarrolladores para actualizar un archivo de versión.
Para determinar qué se ha incluido en un lanzamiento, puede simplemente extraer los registros SVN de la revisión X a la revisión Y y copiar los comentarios en un documento y editarlos para crear un bonito documento de notas de publicación. Lo mismo es cierto para la revisión del código o para diferir las versiones; simplemente use los números de revisión vinculados a su version.html, properties.cs, readme.txt, etc.
También te sugiero tener algún tipo de repositorio de artefactos para guardar tus compilaciones. Si cambia a usar el número de revisión SVN como su número de versión, siempre puede volver a esa revisión exacta en SVN, lo que significa que no necesita etiquetas ni copias de su fuente para cada versión que se encuentre en SVN.