gestión de la liberación en el SVN

Question

Cuando me miro en el SVN ingrese Realmente desearía poder ver los marcadores que me dicen cuando se realizaron lanzamientos. He visto esto en otros sistemas de control de versiones como PVCS y Perforce .

Se puede hacer esto en SVN? He hecho un poco de investigación y hasta ahora parece que no es compatible con este tipo de cosas.

Editar

No quiero tener que copiar nuestra fuente a una carpeta diferente para cada versión. Esto da lugar a una enorme cantidad de duplicación innecesaria de los archivos en la máquina desarrolladores y sólo nos da un registro del número de revisión de cada versión. Puedo hacer que el uso de un documento de texto!

Edit2

Mi objetivo es tener una visión única que me muestra una cronología de mis lanzamientos, entre los que puedo ver todos los cambios de código que tuvieron lugar entre cada versión. Esto entonces hace que sea más fácil para compilar notas de la versión.

Answer 1

Richard, etiquetas están muy cerca, pero me pregunto si lo que necesita podría no ser una rama de lanzamiento dedicado.

Para ello, crea una rama del tronco desde el principio llamado algo así como 'Release'. A continuación, trabajar en el tronco como normal, cuando esté listo para un lanzamiento, fusionar sus cambios desde el tronco hacia 'Release'. Esta es la única manera que usted debe modificar la liberación.

A continuación, puede etiquetar de emisión 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 en el mismo. Averiguar 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 versión hacerlo:

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, usted no está limitado a una versión estrictamente secuencial de todo en el tronco - se puede recoger la cereza revisiones, excluyendo las revisiones si no desea liberarlos por el momento, pero aún incluyendo subsecuente revisiones.

Answer 2

No es como tal. La forma aceptada de hacer comunicados en SVN es tener un directorio "etiquetas", donde se copia su fuente de liberación para cada versión particular. Por ejemplo /tags/release-0.11 ... No hay nada que le impide jugar con el directorio tags por accidente, fuera de la caja, pero algunas personas como para establecer ganchos para prevenir accidentales compromete a liberar las etiquetas pre-commit.

Aquí hay un artículo que describe decente un proceso de liberación en el SVN.

Answer 3

  

Mi objetivo es tener una visión única que   me muestra una cronología de mis lanzamientos,   entre los que puedo ver toda la   cambios en el código que tuvieron lugar entre   cada versión.

¿Ha investigado el gráfico de revisiones Tortoise SVN? Si etiqueta cada versión (que, como otros han señalado no implica la copia de archivos, ya sea en el servidor o la estación de trabajo), entonces usted puede ver todas las revisiones en orden cronológico, con las etiquetas que indican las emisiones reales. Puede diff entre versiones y / o el tronco por hilighting las dos revisiones que interesan y seleccionando Diferenciar desde el menú contextual.

Answer 4

Copia el tronco a una ruta de etiquetas en el repositorio SVN es la forma de lograrlo. Es una copia SVN, por lo que no termine con duplicados de archivos en el servidor de repositorio SVN. Sólo tiene archivos duplicados a nivel local, si opta por retirar una ruta SVN que no sea el tronco. Se compromete en esas copias de trabajo a continuación, volver a la senda SVN fueron sacados de.

Esto es esencialmente una implementación convencional específica de ramificación en el SVN. Echar un vistazo al libro de SVN en línea para obtener más detalles.

Answer 5

El marcador podría ser el mensaje del informe escrito cuando se hace una etiqueta para la liberación (una copia SVN con los / las etiquetas). Al menos ese es el método más común utilizado.

Answer 6

Aunque Subversion no proporciona gestión de la liberación de por sí, herramientas de control de versiones no son por lo general la tarea de esta actividad. Lo que se busca es un problema herramienta de actividad / / cambio de gestión que puede interactuar con la subversión.

Para ello utilizamos Jira en mi lugar de trabajo y que se enlaza con la subversión. Jira proporciona una historia hoja de ruta y el cambio que incluye temas en cada versión. Cada uno de esos temas también tienen enlaces con los cambios en el control de código fuente. De este modo se puede vincular los cambios en el código fuente con las versiones publicadas.

Creo que es generalmente mejor para mantener estas dos herramientas separadas. Aunque Perforce en particular, trata de atar los dos juntos, lo hacen sólo con sencillez. Hay algunas cosas, como correo electrónico a los usuarios de los cambios en temas, añadir comentarios a los temas, añadiendo los archivos adjuntos a los problemas que están mucho mejor realizar en una pieza de software especializado como Jira. Por otro lado Jira no es muy bueno en el control de versiones, la fusión y la ramificación fuente ... que se maneja mejor en una pieza de software especializado como Subversion.

Para una descripción completa, hay otras herramientas que Jira como Bugzilla, Trac, IBM Rational Jazz, etc., que pueden hacer lo mismo con Subversion que hace Jira aunque con diferentes niveles de funcionalidad.

Answer 7

Tome un vistazo a los temas del libro SVN:

Etiquetas y navegación de repositorios

etiquetas y ramas son "copia en escritura", lo que significa que no hay copias adicionales en el repositorio. En general, un desarrollador individual no tendría que tener una copia local a menos que lo necesitaba por una razón (POR EJEMPLO desarrollar en una rama).

Si etiqueta cada lanzamiento, a continuación, puede ver las etiquetas de visualización del repositorio. Los enlaces de arriba hablan directamente acerca de las herramientas de línea de comandos, pero también hay herramientas GUI como TortoiseSVN en Windows. Usted puede obtener la historia, hacer comparaciones, etc.

Para ver los cambios realizados en un comunicado, que acaba de mostrar un registro del tronco de la revisión de la etiqueta que desea volver a la revisión de la etiqueta anterior 1. Suena como un trabajo extra, pero es bastante sencillo una vez que se acostumbre a ella.

Con nuestras herramientas de construcción, también cometer un archivo con información número de versión hasta el tronco, y el comentario tiene el número de versión de la construcción. Si el código principal está en el tronco, esto también puede funcionar como un marcador para lo que está en una acumulación (busque entre la versión compromete).

Answer 8

1 para usar el mensaje de confirmación.

Para un proyecto que crea un usuario llamado SVN acumulación. La construcción de la máquina utiliza esta entrada para SVN. Siempre que la máquina de construcción / proceso hizo una acumulación también actualiza un archivo y el SVN mensaje era la versión / otro identificador para la construcción.

A continuación, también hemos creado una etiqueta para esa construcción. De esta manera en el maletero, podíamos ver el construye cuando / donde se intercalan con otros cambios.

Así que mi sugerencia (forma más sencilla de hacerlo) es crear otros archivos llamados acumulación (o cualquier otra cosa que desee) y añadir a la cuenta o modificarlo en su escritura de la estructura / proceso y compruebe de nuevo en / cometen con el nombre de la versión de lanzamiento como el mensaje de confirmación. Sencillo. A continuación, se mostrará en sus consultas historia.

Answer 9

Además, si usted sabe qué revisiones se están comparando se puede hacer un diff SVN y verá qué archivos han cambiado y cómo entre las dos revisiones.

No está seguro acerca de su configuración total, pero alguien mencionado TortoiseSVN. Eso es definitivamente un buen comienzo. Yo personalmente uso Eclipse con el Subclipse plug-in y me permite realizo diferenciaciones en un entorno gráfico entre revisiones. Como siempre y cuando tenga su proyecto su puede comparar cualquier revisión de cualquier otra revisión y, como tal, que no es necesario tener todo tipo de duplicación de archivos.

Además, por lo general establecimos tres directorios en cada repositorio. Ramas, tronco y las etiquetas. Como alguien señaló, las etiquetas se utilizan específicamente para la identificación de un comunicado.

Answer 10

Me encuentro con el mismo problema y la forma en que he tratado de solucionarlo para mi empresa es tener una carpeta 'liberación' en el maletero, esta carpeta sólo contiene el ejecutable real o lo que tiene que ser parte de la implementación.

se crea una nueva carpeta para cada versión que empiezan con '1.0.0.0' en 'liberación' carpeta y también marcar el código con el nombre de la carpeta misma versión 1.0.0.0 es decir en el caso.

No estoy seguro de si es la forma correcta de hacerlo, pero que resuelve mi problema de averiguar ejecutable que he desplegado.

Answer 11

Si usted sigue la convención normal de SVN "etiquetas / ramas / tronco" en la raíz de su repositorio, los desarrolladores normalmente no quieren que echa un vistazo a todo el repositorio, sólo desde el tronco hacia abajo.

Answer 12

Me gustaría ofrecer un enfoque diferente que debe ayudar a resolver su problema planteado: la creación de notas de la versión y la visualización de las diferencias entre versiones de código.

Utilizamos una utilidad llamada SubWCRev que viene con Tortoise SVN. Tenemos un evento posterior a la generación que se agarra el número de revisión SVN y se pega en un archivo - en el caso de sitios web que ponemos esto en un archivo llamado version.html. A continuación, en cualquier punto en el tiempo se puede atar su liberación (ya sea los releas actualmente en control de calidad, Prod, o cualquier otro ambiente) para el número de revisión exacta en SVN. No más marcado, no más preguntándose lo que está incluido en un comunicado, no más de escuchas desarrolladores para actualizar una versión de archivo.

Con el fin de determinar lo que se ha incluido en un comunicado, a continuación, puede simplemente tirar de seguridad de los registros de la revisión de SVN X para la revisión Y y copiar los comentarios en un documento y de edición para hacer un lanzamiento bastante documento de notas. Lo mismo es cierto para la revisión de código o diffing las liberaciones; sólo tiene que utilizar los números de revisión atadas a su version.html, properties.cs, readme.txt, etc.

También me gustaría sugerir que tenga algún tipo de repositorio de artefactos para mantener su construye. Si cambia a utilizar el número de revisión SVN como su número de versión, siempre se puede volver a esa revisión exacta en SVN lo que significa que no necesita etiquetas o copias de su fuente para cada versión por ahí en el SVN.

Answer 13

Para su información,

copia SVN no está en papel, es sólo la vinculación por lo tanto no tendrá ningún espacio aparte de los archivos modificados. Y esas versiones tendrán el espacio de todos modos. Por lo tanto la creación de una copia para cada lanzamiento no se llevará a cualquier espacio.