¿Cómo crear correctamente una etiqueta SVN desde el tronco?


282

Estoy creando mi primer proyecto en Subversion . Hasta ahora tengo

 branches
 tags
 trunk

Creo que inmediatamente necesito hacer que las ramas sean singulares y comenzar de nuevo. Actualizar ramas es la norma.

He estado trabajando en el tronco y moviendo el contenido a las etiquetas de la siguiente manera.

mkdir tags/1.0
cp -rf trunk/* tags/1.0
svn add tags/1.0
svn commit -m " create a first tagged version"

Mi instinto me dice que esto está totalmente mal, y que debería mantener alguna relación entre los archivos que utilizo svn copy. Los archivos que creo de esta manera no tendrán relación entre sí, y estoy seguro de que perderé las funciones de Subversion. ¿Estoy en lo correcto?

¿Debo usar svn copy para los archivos individuales?

mkdir tags/1.0
svn add tags/1.0
svn copy trunk/file1 tags/1.0
svn copy trunk/file2 tags/1.0
svn copy trunk/file3 tags/1.0
svn commit -m " create a first tagged version"

¿Debo usar svn copy en todo el directorio?

svn copy cp -rf trunk tags/1.0
svn commit -m " create a first tagged version"

10
Desafortunadamente no tomo todas las decisiones en este caso ... git es bastante mágico.
ojblass

Respuestas:


186

Tiene razón en que no es "correcto" agregar archivos a la carpeta de etiquetas.

Has adivinado correctamente que copyes la operación a utilizar; permite a Subversion realizar un seguimiento del historial de estos archivos y también (supongo) almacenarlos de manera mucho más eficiente.

En mi experiencia, es mejor hacer copias ("instantáneas") de proyectos completos, es decir, todos los archivos desde la ubicación de extracción de raíz. De esta forma, la instantánea puede sostenerse por sí sola, como una representación real del estado del proyecto completo en un momento determinado.

Esta parte de "el libro" muestra cómo se usa típicamente el comando.


15
La versión 1.1 del libro está terriblemente desactualizada. Aquí hay un mejor enlace: svnbook.red-bean.com/nightly/en/svn.branchmerge.tags.html
Quinn Taylor el

1
los archivos copiados no gastan espacio adicional
Carlos

424

Utilizar:

svn copy http://svn.example.com/project/trunk \
      http://svn.example.com/project/tags/1.0 -m "Release 1.0"

Taquigrafía:

cd /path/to/project
svn copy ^/trunk ^/tags/1.0 -m "Release 1.0"

36
Marqué esto como respuesta. Solo una nota extra. Puede obtener una revisión previa del tronco y "etiquetarlo" también. el comando: svn copy -r 123 " svn.example.com/project/trunk " " svn.example.com/project/tags/1.0 " -m "Etiquetado, pero utilizando una revisión anterior (123)".
granadaCoder

77
Obtengo svn: las operaciones locales sin compromiso no toman un mensaje de registro o propiedades de revisión , así que simplemente elimino la opción -m.
Jonny

44
Solo para su información, asegúrese de que su URL coincida con su repositorio, incluidos http o https.
Norman H

2
¿Por qué el \ al final de la primera línea?
Fractaliste

1
@ Jonny No puedo ejecutar el comando anterior sin la opción "-m". Estoy usando terminal en mac.
Abdurrahman Mubeen Ali

14

Como señaló @victor hugo, la forma "adecuada" es usar svn copy. Sin embargo, hay una advertencia. La "etiqueta" creada de esa manera no será una etiqueta verdadera, será una copia exacta de la revisión especificada, pero será una revisión diferente en sí misma. Entonces, si su sistema de compilación utiliza la revisión svn de alguna manera (por ejemplo, incorpora el número obtenido con 'svn info' en la versión del producto que construye), entonces no podrá construir exactamente el mismo producto desde una etiqueta (el El resultado tendrá la revisión de la etiqueta en lugar de la del código original).

Parece que, por diseño, en svn no hay forma de crear una metaetiqueta verdaderamente adecuada.


44
Es posible utilizar "Última modificación modificada": echo "{ 'svnRev': \"`svn info | awk '/Last Changed Rev:/{print $4}'`\" }" >svnver.txt`
18446744073709551615

De esta manera, dos ramas con (por supuesto) números de revisión diferentes todavía producen la misma versión de software.
18446744073709551615

1
Sí, tiene razón acerca de Last Changed Rev, pero eso no cambia el hecho de que, por diseño, no hay etiquetas reales en Subversion.
Alexander Amelkin

@ 18446744073709551615: puede evitar usar awky obtener esa información directamente de svn usando la --show-itemopción:svn info --show-item last-changed-revision
Luchostein

12

Solo usa esto:

svn  copy  http://svn.example.com/project/trunk  
           http://svn.example.com/project/branches/release-1
           -m  "branch for release 1.0"

(todo en una línea, por supuesto). Siempre debe hacer una rama de toda la carpeta troncal y el contenido. Por supuesto, es posible ramificar sub-partes del tronco, pero esto casi nunca será una buena práctica. Desea que la rama se comporte exactamente como el tronco ahora, y para que eso suceda, debe ramificar todo el tronco.

Vea un mejor resumen del uso de SVN en mi blog: SVN Essentials y SVN Essentials 2


¿Puedes explicar cómo debería ser si solo comprobo desde el tronco y estoy dentro con mi script?
aholbreich

Si ha desprotegido la carpeta troncal, debe usar la dirección http del repositorio. He actualizado la respuesta para representar esto, ya que verificar la carpeta de troncales es el patrón recomendado.
AgilePro

¿Cómo es esta respuesta diferente de la aceptada?
Daniel


7

@victor hugo y @unwind son correctos, y la solución de victor es, con mucho, la más simple. Sin embargo, CUIDADO con los elementos externos en su proyecto SVN. Si hace referencia a bibliotecas externas, la referencia de revisión externa (ya sea una etiqueta, HEAD o número) permanecerá sin cambios cuando etiquete directorios que tienen referencias externas.

Es posible crear una secuencia de comandos para manejar este aspecto del etiquetado, para una discusión sobre ese tema, consulte este artículo de SO: Etiquetado de un pago SVN con elementos externos


5

Otra opción para etiquetar un repositorio Subversion es agregar la etiqueta a la propiedad svn: log de esta manera:

   echo "TAG: your_tag_text" > newlog
   svn propget $REPO --revprop -r $tagged_revision >> newlog
   svn propset $REPO --revprop -r $tagged_revision -F newlog
   rm newlog

Recientemente comencé a pensar que esta es la forma más "correcta" de etiquetar. De esta forma no crea revisiones adicionales (como lo hace con "svn cp") y aún puede extraer fácilmente todas las etiquetas usando grep en la salida de "svn log":

   svn log | awk '/----/ {
                      expect_rev=1;
                      expect_tag=0;
                  }
                  /^r[[:digit:]]+/ {
                      if(expect_rev) {
                          rev=$1;
                          expect_tag=1;
                          expect_rev=0;
                      }
                  }
                  /^TAG:/ {
                      if(expect_tag) {
                          print "Revision "rev", Tag: "$2;
                      }
                      expect_tag=0;
                  }'

Además, de esta manera puede eliminar etiquetas sin problemas si es necesario. Entonces las etiquetas se convierten en una metainformación completa, y me gusta.


0
svn copy http://URL/svn/trukSource http://URL/svn/tagDestination -m "Test tag code" 
  $error[0].Exception | Select-object Data

Todo lo que tienes que hacer es cambiar la ruta de la URL. Este comando creará un nuevo directorio "tagDestination". La segunda línea le informará los detalles completos del error si ocurre alguno. Cree la variable svn env si no se creó. Puede verificar (Cmd: - set, Powershell: - Get-ChildItem Env :) La ruta predeterminada es "C: \ Archivos de programa \ TortoiseSVN \ bin \ TortoiseProc.exe"


-4

Prueba esto. Esto funciona para mi:

mkdir <repos>/tags/Release1.0
svn commit <repos>/tags/Release1.0 
svn copy <repos>/trunk/* <repos>/tag/Release1.0
svn commit <repos/tags/Release1.0 -m "Tagging Release1.0"

1
Este es definitivamente un camino equivocado. La etiqueta (Release1.0) debe ser una copia del directorio fuente (troncal), no un directorio creado arbitrariamente. Si lo hace de la manera que lo hizo, pierde el historial del directorio de origen y solo mantiene el historial de los nodos descendientes (archivos y directorios).
Alexander Amelkin
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.