Subversion: ¿Se pueden realizar varias operaciones de copia en una sola revisión?

Question

Por lo que entiendo acerca de las transacciones en Subversion esto debería ser posible en principio, pero no conozco ninguna herramienta que lo soporte.

El trasfondo es que estamos discutiendo una migración de PVCS Dimensions a Subversion, y la característica principal que se cita como faltante en Subversion es "Design Parts". Una parte de diseño es una colección arbitraria de archivos que pueden manejarse juntos, p. todos los archivos fuente necesarios para un subproyecto.

Una idea para reemplazar esto es mediante operaciones de copia en un Makefile, que copia los archivos relevantes en una rama. Pero si todos los archivos se copian por separado, esto puede llevar a muchas revisiones, lo que puede complicar el historial, por lo que sería bueno evitar eso.

EDIT: Algunos más información de fondo:

El proyecto consta de varios sub-proyectos (5-10) que se liberan por separado, pero que comparten algunos archivos de origen comunes y bibliotecas externas importadas de otros proyectos.

Uno de los motivos citados para las piezas de diseño es restringir las dependencias de los archivos fuente, otro es para gestionar los productos de los subproyectos, de modo que todos ellos se puedan actualizar en una sola operación. Ambos tipos de archivos están algo salpicados en los directorios.

Somos aproximadamente 5 desarrolladores en el proyecto.

Answer 1

Puede hacer las copias en una copia de trabajo y enviarlas todas a la vez. Eso crea solo una revisión.

Con la línea de comandos en el cliente podría parecerse a lo siguiente:

svn copy file1 directory 
svn copy file2 directory 
svn copy file3 directory 
svn commit 

El principal inconveniente es que necesita una copia de trabajo y esta copia de trabajo tiene que incluir la fuente- y directorio-objetivo.

Answer 2

¿Por qué no pones tu subproyecto en un subdirectorio propio?

Project 
    | 
    ---> Subproject 1 
    ---> Subproject 2 
    Files from project. 

De esta manera siempre se puede operar en un subproyecto completo.

Aquí tenemos:

Project 
    | 
    ---> common Files 
    ---> Subprojects... 

Answer 3

Si todos los proyectos estaban en sus propios repositorios, SVN externos pueden hacer el truco

Answer 4

Hay una svnmucc herramienta que hace exactamente esto, sin necesidad de una copia de trabajo:

http://subversion.tigris.org/tools_contrib.html#svnmucc_c

Answer 5

Esto es bastante interesante, acabo de tener una lectura rápida de las piezas de diseño, a partir de lo que he entendido, por Al dividir de manera efectiva los archivos individualmente en una estructura arbitraria, se dirigirá a un mundo de dolor cuando empiece a fusionar las cosas en su ubicación original (y la fusión probablemente no se realizará en una única confirmación a través de todo el archivos).

Pero creo que se puede hacer una cosa similar a diseñar piezas de la subversión con un poco de ajuste:

En primer lugar, una parte del diseño se puede simular el uso externo (1.6 permite a los externos a apuntan a archivos, así como los directorios) Para hacer esto, usted puede configurar su proyecto jerarquía de la siguiente manera:

/project1 
/trunk 
    /doc 
    /design1 
    /release2 
    /src 
    /subproject1 
    /subproject2 
/tags 
/branches 
/parts 
    /part1 
    /part2 
    /part3 

Cada carpeta piezas solamente contendría un "svn: externos" propiedad que trae en los archivos apropiados para esa parte en el sububicación apropiada, como:

svn:externals 

../../trunk/src/subproject1  src/subproject1 
../../trunk/doc/release2   doc/release2 

a continuación, pago y envío de la pieza, en lugar de tronco, y se obtiene una copia de trabajo que contiene sólo los archivos que desea en la estructura que define la parte, y cuando se comprometa, que vas directamente en el tronco - no se requiere fusión aquí.

También puede baseline sus partes ramificando primero la totalidad de la cajuela (económica y rápida), y luego cambiando la parte externa para apuntar a la rama en lugar de la cajuela principal. Esto no aumenta el tamaño del repositorio, y su copia de trabajo mantiene exactamente la misma estructura, solo obtiene todos sus archivos de la sucursal en lugar de la troncal. Cualquier actualización de esa parte también va en contra de la sucursal: la fusión de los cambios de la parte es simplemente una fusión estándar de reintegración de la bifurcación de la bifurcación en trunk, que es la práctica estándar de svn.

Administrar la definición de partes se vuelve más interesante, ya que en el esquema anterior, cada parte se define manualmente y no son jerárquicas. Necesitarías algún tipo de script (quizás makefile) que conozca la jerarquía de partes y, dado el nombre de una parte, pueda construir las definiciones externas apropiadas que luego puedan aplicarse a un directorio de partes.

Por lo tanto, aunque subversion no proporciona explícitamente la capa de abstracción de las partes, se puede modelar manualmente con bastante precisión: solo está limitado por las capacidades de svn: externals y las secuencias de comandos que utiliza para administrarlas.

Answer 6

Se puede utilizar: svn copy FROM_URL1 FROM_URL2 URL_TO

Por ejemplo:

svn copy svn://192.168.1.50/trunk/folder1 svn://192.168.1.50/trunk/folder2 svn://192.168.1.50/tags/MY_TAG 

Answer 7

que estaba frente a un problema similar: cómo copiar varios archivos, dispersos en el repositorio en una etiqueta y que sea rápido en una transacción de este modo una revisión forma más sencilla es crear el directorio temporal de copia de trabajo, copiar todos los archivos necesarios allí y luego copiar copia de trabajo al repositorio remoto y eliminar el directorio temporal:

svn mkdir TMP_DIR 
svn mkdir TMP_DIR\MY_TAG 
svn cp --parents src\test\File.txt TMP_DIR\MY_TAG\src\test\File.txt 
svn cp --parents src\test2\File2.txt TMP_DIR\MY_TAG\src\test2\File2.txt 
svn cp -m "comment" TMP_DIR\MY_TAG "http://myrepohost/myrepo/tags/" 
svn rm --force TMP_DIR 

espero que ayude.

Answer 8

Su organización del flujo de trabajo/código es incorrecto:

Si tienes código compartido entre paquetes separados, esto pertenece claramente en una separada. un árbol por paquete

poner varios paquetes (de versiones específicas) juntos en algún ambiente pertenece sobre una capa separada por encima (por ejemplo, un producto de software más grande que consta de varios, posiblemente opcional, componentes.): La distribución, y se maneja por el infraestructura de gestión de paquetes de distribución