Otro concepto común en el control de versiones es la etiqueta. Una etiqueta no es más que una “instantánea” del proyecto en el tiempo. En Subversion, esta idea ya está presente en todas partes. Cada revisión del repositorio es exactamente eso—una instantánea del sistema de ficheros tras cada envío al repositorio.
No obstante, las personas prefieren dar nombres más
familiares a las etiquetas, como lanzamiento-1.0.
Y quieren hacer instantáneas de subdirectorios menores
del sistema de archivos. Después de todo, no es tan fácil
recordar que lanzamiento-1.0 de una parte del software es un
subdirectorio particular de la revisión 4822.
De nuevo, svn copy viene al
rescate. Si desea crear una instantánea de
/calc/trunk exactamente tal y como
se ve en la revisión HEAD, haga una
copia:
$ svn copy http://svn.example.com/repos/calc/trunk \
http://svn.example.com/repos/calc/tags/release-1.0 \
-m "Tagging the 1.0 release of the 'calc' project."
Committed revision 351.
Este ejemplo asume que ya existe un directorio
/calc/tags. (Si no existe,
vea svn mkdir).
Tras finalizar la copia, el nuevo directorio
lanzamiento-1.0 será para siempre
una instantánea del aspecto que tenía la revisión
HEAD del proyecto en el momento que
realizó la copia. Por supuesto puede querer ser más
preciso sobre qué revisión exacta copiar, en caso de
que alguien realice un cambio al proyecto mientras no
está observando. Así que si sabe que la revisión 350
de /calc/trunk es exactamente la
instantánea que desea, puede especificarla pasando -r
350 al comando svn copy.
Pero espere un momento: ¿no es este procedimiento para crear etiquetas el mismo que usamos para crear una rama? Si, de hecho, así es. En Subversion no hay diferencia entre una etiqueta y una rama. Ambas son directorios ordinarios que son creados a partir de una copia. Igual que con las ramas, la única razón por la que un directorio copiado es una “etiqueta” es porque los humanos han decidido tratarlo de ese modo: mientras nadie envíe cambios usando ese directorio, seguirá siendo siempre una instantánea. Si la gente comienza a realizar cambios, se convierte en una rama.
Si está administrando un repositorio, hay dos formas de de gestionar etiquetas. La primera es “manos fuera”: según la política de su proyecto, decida dónde pondrá sus etiquetas, y asegúrese de que todos los usuarios saben cómo tratar los directorios que copian ahí. (En otras palabras, asegúrese de que no cambian nada en esos directorios.) La segunda forma es más paranoica: puede usar uno de los scripts de control de acceso proporcionados con Subversion para prevenir cualquier cosa que no sea la creación de nuevas copias en el área de etiquetado (Vea Capítulo 6, Configuración del servidor.) No obstante, el método paranoico normalmente no es necesario. Si un usuario envía un cambio accidentalmente al directorio de etiquetas, puede simplemente deshacer el cambio tal y como discutimos en la sección anterior. Después de todo, esto es control de versiones.
A veces quiere que su “instantánea” sea más complicada que un solo directorio de una revisión concreta.
Por ejemplo, pretendamos que su proyecto es mucho más
grande que nuestro ejemplo calc:
suponga que contiene un número de subdirectorios y muchos más
ficheros. Realizando su trabajo, puede decidir que necesita
crear una copia de trabajo local diseñada para contener
características o correcciones de fallos específicas. Puede
conseguir esto modificando ficheros o directorios de forma
selectiva para que reflejen una revisión particular (usando
svn update -r liberalmente), o cambiando
ficheros y directorios a ramas particulares (haciendo uso
de svn switch). Cuando ha finalizado, su
copia local es un batiburrillo de ubicaciones del repositorio
de diferentes versiones. Pero tras hacer unas pruebas, sabe
que es la combinación precisa de datos que necesita.
Hora de tomar una instantánea. Copiar una URL en otra no funcionará esta vez. En este caso, quiere hacer una instantánea de la configuración exacta de su copia local y almacenarla en el repositorio. Afortunadamente, svn copy tiene en realidad cuatro usos diferentes (sobre los cuales puede leer en el noveno capítulo), incluyendo la habilidad para copiar el árbol de una copia local al repositorio:
$ ls my-working-copy/ $ svn copy my-working-copy http://svn.example.com/repos/calc/tags/mytag Committed revision 352.
Ahora existe un nuevo directorio en el repositorio,
/calc/tags/mytag, el cual
es una instantánea exacta de su copia local de
trabajo—revisiones mezcladas, urls, y todo eso.
Otros usuarios han encontrado usos interesantes de esta característica. A veces hay situaciones en las que acaba de enviar al repositorio un grupo de cambios locales, y querría que los viese un colaborador. En lugar de ejecutar svn diff y enviar el fichero de parche (el cual no captura cambios en el árbol), puede usar en su lugar svn copy para “subir” su copia local a un área privada del repositorio. Entonces su colaborador puede o bien obtener una copia tal cual de su copia local, o bien usar svn merge para recibir sus cambios exactos.