Creación automática de una etiqueta en subversión

Question

Mantengo el sistema de compilación en mi empresa, que actualmente utiliza CVS. Este sistema de compilación se usa en múltiples proyectos y múltiples repositorios de CVS.

Cuando tengamos un hito de lanzamiento, creamos una etiqueta. En CVS, esto es fácil:

$ cvs tag TAG_NAME 

Ese comando funciona independientemente del módulo CVS o repositorio, con tal de que se ejecuta en un directorio de trabajo de CVS.

Para hacer lo mismo en subversión, parece que primero tendré que analizar el resultado de svn info para obtener la raíz del repositorio. Entonces puedo crear la etiqueta con:

svn cp . $REPO_ROOT/tags/TAG_NAME -m"Created tag TAG_NAME" 

Por supuesto, esto asume que el repositorio SVN tiene el "tronco, las etiquetas, las ramas" estructura de directorios recomendados. Entonces para estar seguro probablemente necesite verificar esto primero.

Parece un montón de trabajo simplemente asignar un número de revisión a un nombre simbólico. ¿Hay una mejor manera?

Answer 1

Aquí es cómo he implementado este, por si alguien tiene curiosidad:

<!-- First, we need to get the svn repository root URL by parsing 
the output of 'svn info'. --> 
<exec executable="svn" failonerror="yes"> 
    <arg line="info"/> 

    <redirector outputproperty="svninfo.out" errorproperty="svninfo.err"> 
     <outputfilterchain> 
      <linecontains> 
       <contains value="Repository Root: "/> 
      </linecontains> 

      <tokenfilter> 
       <replacestring from="Repository Root: " to=""/> 
      </tokenfilter> 
     </outputfilterchain> 
    </redirector> 
</exec> 

<echo level="verbose" message="Root from svn info: ${svninfo.out}"/> 

<!-- Set the svn.root property from the svn info output, and append 
the module prefix if it exists. The module prefix allows multiple 
projects to use the same repository root. --> 
<condition property="svn.root" value="${svninfo.out}/${svn.module.prefix}"> 
    <isset property="svn.module.prefix"/> 
</condition> 
<!-- Note that the next line will have no effect if the property was 
set in the condition above, since ant properties are immutable. The 
effect is an "else", if the condition above is NOT true. --> 
<property name="svn.root" value="${svninfo.out}"/> 
<echo level="verbose" message="Root: ${svn.root}"/> 

<!-- Verify the tags directory exists. --> 
<exec executable="svn" 
     failonerror="no" 
     outputproperty="null" 
     errorproperty="svn.ls.error"> 
    <arg line="ls ${svn.root}/tags"/> 
</exec> 
<fail> 
Cannot find 'tags' subdirectory. 

${svn.ls.error} 

The subversion repository is expected to have 'trunk', 'branches', and 'tags' 
subdirectories. The tag '${tag}' will need to be manually created. 
    <condition> 
     <not> 
      <equals arg1="${svn.ls.error}" arg2="" trim="yes"/> 
     </not> 
    </condition> 
</fail> 

<!-- Finally, do the actual tag (copy in subversion). --> 
<exec executable="svn" failonerror="yes"> 
    <arg line="cp . ${svn.root}/tags/${tag} -m 'Created tag ${tag}'"/> 
</exec> 

También quiero señalar que soy consciente de las diferencias entre CVS y subversión con respecto al etiquetado, y que la subversión la revisión es, para todos los propósitos prácticos, equivalente a la etiqueta. Desafortunadamente, eso no es realmente relevante; mis usuarios quieren un nombre simbólico compuesto por el nombre del módulo y un número de versión (diferente).

Answer 2

A diferencia de CVS, las etiquetas son más que un nombre simbólico en las subversiones, ese es el punto. Nosotros creamos una etiqueta, en realidad estás creando una rama. Recomiendo leer esto, si no lo has hecho ya: http://svnbook.red-bean.com/

Answer 3

Utilizo svn casi exclusivamente desde la línea de comandos y rápidamente me cansé de escribir en las URL de los monstruos. Finalmente escribí un script svnurl, que uso desde el shell. Opera en el supuesto de que un "proyecto" tienes la forma:

.../PROJECTNAME/trunk 
       tags 
       branches 

Supongamos que está en algún lugar de una copia de trabajo de PROJECTNAME/ramas/foo:

svnurl -tl # gives a list of tags for the current project 
svnurl -tlu # the same as full urls 
svnurl -t 1.1 # the url for the tag 1.1 of the current project 
# analagous functions for branches 
svnurl -ru # the url of the "root" of the current working copy 
      # eg svn://.../PROJECTNAME/branches/foo 
svnurl -T # the url of the trunk of the current project 
svnurl -pn # the name of the current project, `PROJECTNAME` 
# ... 

uso es como la siguiente:

$ svn cp $(svnurl -T) $(svnurl -t 1.1.1) # tag trunk as 1.1.1 

El código no es bonito, pero me ha ahorrado muchas pulsaciones de teclas y ha sido útil en formas que no esperaba. Estaría dispuesto a compartirlo si estás interesado.

Answer 4

Falta un principio básico de Subversion: el número de revisión es la etiqueta. Cuando lo "etiqueta" con svn cp, solo está haciendo una copia de esa revisión en particular con un nombre más largo. Y a diferencia de una etiqueta CVS, usted (u otros desarrolladores) podría continuar desarrollando continuamente esa "etiqueta". No es una entidad estática como una etiqueta CVS es (bueno, para ser justos, puede mover una etiqueta en archivos CVS individuales que efectivamente la "modifique").

La mayoría de los usuarios de svn tratan las etiquetas tal como CVS las presentó. Y (bajo Apache, al menos) puede configurar el servidor DAV para no permitir escrituras/registros en cualquier directorio de etiquetas. No he intentado esto, y podría evitar el uso de direcciones URL de http para crear las etiquetas (tendría que usar rutas de acceso de archivos desde un shell en la máquina de alojamiento). Pero para todos los propósitos prácticos, su proceso de publicación debería interesarse más en el número de revisión específico que en alguna cadena de texto arbitraria. Este último puede ser alterado después del lanzamiento; el primero debe [*] siempre darle acceso al mismo conjunto exacto de archivos cada vez que lo verifique.

[*] Siempre hay una manera de juguetear con los archivos detrás de escena, después del hecho ... Solía ​​editar manualmente los archivos RCS y CVS con vi cuando necesitaba arreglar un comentario, etc.Pero sin una gran habilidad svn-intelligence, un número de revisión dado debería ser bastante constante.