svn: reemplazar tronco con rama


155

¿Cuál es la mejor manera de hacer que una de las ramas de un repositorio de subversión sea el nuevo tronco?

Ha habido una gran reescritura para todo el sistema: las cosas se han movido, reescrito, reemplazado, eliminado, renombrado, etc. El código reescrito ha sido probado y está listo para reemplazar el viejo baúl.

Básicamente, la antigua línea principal (Trunk 5) está etiquetada y terminará aquí. La rama reescrita (Rama 6) se convertirá en la nueva línea principal (Troncal 7):

Tronco (1) -> Tronco (2) -> Tronco (5) -> × + -> nuevo Tronco (7)
  \ \ |
  tenedor de fusión?
    \ \ |
     + -> Rama (3) -> Rama (4) -> Rama (6) - +

Todos los cambios en curso desde el viejo 'Tronco' ya están incorporados en la 'Rama reescrita'

¿Cómo puedo hacer esto?

Respuestas:


118

Use svn move para mover el contenido del viejo tronco a otro lugar y cambie el nombre de la rama al tronco después.

Tenga en cuenta que copiar y mover en svn funcionan como operaciones de archivo. Puede usarlos para mover / copiar cosas en su repositorio y estos cambios también están versionados. Piense en "mover" como "copiar + eliminar".

[EDITAR] Nilbus acaba de notificarme que obtendrás conflictos de fusión cuando lo uses svn move.

Sigo pensando que este es el enfoque correcto. Causará conflictos, pero si se fusiona con cuidado, es probable que no pierda ningún dato. Si eso te molesta, usa un mejor VCS como Mercurial o Git .


1
Si hace esto, cualquier persona con cambios en una copia de trabajo en la troncal original tendrá un conflicto, incluso si sus cambios deberían fusionarse. Esto se debe a que los archivos se eliminan y se vuelven a agregar: se tratan como objetos separados con un historial separado.
Edward Anderson el

@nilbus: ¿Lo intentaste? IIRC, SVN muestra que los archivos fueron eliminados y leídos, pero internamente, sabrá que los archivos se han movido.
Aaron Digulla

Si. Revisé dos copias. En la primera copia, moví el directorio A a A2 y el directorio B a A. Luego moví A a B, luego A2 a A. (renombrar y renombrar). En el segundo pago, hice un cambio en un archivo e intenté svn actualizar. Conflicto porque el archivo que cambié "fue eliminado". Internamente no guarda copias duplicadas de los archivos, pero la eliminación que ves realmente te afecta cuando se trata de conflictos.
Edward Anderson el

12
@nilbus: En este punto, me gustaría citar a Linus Torvalds: "El lema de Subversion por un tiempo fue" CVS hecho bien ", o algo así, y si comienzas con ese tipo de eslogan, no hay ningún lugar donde puedas ir. No hay forma de hacer CVS correctamente ".
Aaron Digulla

3
Sí. Estoy de acuerdo Para resolver este problema, en realidad revisé el repositorio con svn-git, y usé git para volver a crear la rama en el maestro.
Edward Anderson el

66

Estoy de acuerdo con usar el comando svn move para lograr este objetivo.

Sé que otros aquí piensan que es inusual, pero me gusta hacerlo de esta manera. Cuando tengo una rama de características y estoy listo para fusionarla con una troncal que también se ha modificado significativamente, la fusionaré con una nueva rama, generalmente llamada <FeatureBranchName>-Merged. Luego resuelvo conflictos y pruebo el código combinado. Una vez que está completo, muevo el tronco a la carpeta de etiquetas para no perder nada. Finalmente me muevo <FeatureBranchName>-Mergedal baúl.

Además, prefiero evitar la copia de trabajo al hacer los movimientos, aquí hay ejemplos de los comandos:

svn move https://SVNUrl/svn/Repo/trunk https://SVNUrl/svn/Repo/tags/AnyName

svn move https://SVNUrl/svn/Repo/branches/BranchName-Merged https://SVNUrl/svn/Repo/trunk

Nota: yo uso 1.5


1
Puede que esa no sea la mejor práctica, pero sin duda es la más eficiente cuando se tiene un tronco muy antiguo y todos trabajaron en una rama como si fuera el tronco. ¡Resolvió mi problema!
Alex Perrin el

12

Estaba viendo este problema recientemente, y la solución con la que estaba muy contento fue realizar

svn merge --ignore-ancestry trunk-url branch-url

en la copia de trabajo de mi baúl.

Esto no intenta aplicar los cambios de manera histórica (manteniendo los cambios en el tronco). Simplemente "aplica la diferencia" entre el tronco y la rama. Esto no creará ningún conflicto para sus usuarios en los archivos que no fueron modificados. Sin embargo, perderá su información histórica de la rama, pero eso sucede cuando realiza una fusión de todos modos.


1
Después de svn 1.5, debería poder hacer fusiones que preserven el historial.
NSherwin

9

Le recomendamos que realice estos cambios a través de la herramienta de navegador de repositorio.

Intentar grandes operaciones de borrar + mover a través de la copia de trabajo es una excelente manera de eliminar la copia de trabajo. Si se ve obligado a usar la copia de trabajo, realice confirmaciones incrementales después de cada operación de eliminación o movimiento y ACTUALICE su copia de trabajo después de cada confirmación.


Un enlace a Repo sería útil (solo por conveniencia, guarde una búsqueda en Google :))
Brian M. Hunt el

3
Lo siento. La ortografía hizo que pareciera que me refería a una herramienta específica (editada). En realidad, la mayoría de las herramientas de la GUI de SVN deberían tener una función de navegador de repositorio. FYI: uso tortuga tortoisesvn.tigris.org
Chris Nava el

4

Si desea hacer que la rama sea la nueva troncal (es decir), deshacerse de todos los cambios en la troncal que se hicieron desde que se creó la rama, puede 1. Crear una rama del tronco (para fines de respaldo) 2. "revertir los cambios "en el enlace troncal (seleccione todas las revisiones después de crear el ramal 3. Combine el ramal nuevamente con el tronco.

La historia debería permanecer así.

Saludos, Roger


3

Las soluciones @Aaron Digulla y @kementeus son viables. Para los repositorios de Subversion 1.4, las operaciones de copiar / mover pueden dificultar la migración futura a una estructura de repositorio diferente o dividir los repositorios.

Creo que las mejoras de 1.5 incluyen una mejor resolución del historial de movimiento / copia, por lo que probablemente no sería un problema para un repositorio de 1.5.

Para un repositorio 1.4, recomendaría usar svnadmin dumpy svndumpfilterrealizar el movimiento del tronco existente en otro lugar, luego mover la rama al tronco con el mismo mecanismo. Cargue los dos archivos de volcado en un repositorio de prueba, verifique y luego muévalo a producción.

Por supuesto, haga una copia de seguridad de su repositorio existente antes de comenzar.

Esto preserva el historial sin registrar el movimiento / copia explícitamente y facilita la futura reorganización, preservando el historial.


Editar: según lo solicitado, la documentación del comportamiento 1.4, del libro 1.4 Red-Bean, Filtering Repository History

Además, las rutas copiadas pueden darte algunos problemas. Subversion admite operaciones de copia en el repositorio, donde se crea una nueva ruta copiando alguna ruta ya existente. Es posible que en algún momento de la vida útil de su repositorio, haya copiado un archivo o directorio de una ubicación que svndumpfilterestá excluyendo, a una ubicación que está incluyendo. Para que los datos de volcado sean autosuficientes,svndumpfilteraún debe mostrar la adición de la nueva ruta, incluido el contenido de los archivos creados por la copia, y no representar esa adición como una copia de una fuente que no existirá en su flujo de datos de volcado filtrado. Pero debido a que el formato de volcado del repositorio de Subversion solo muestra lo que se modificó en cada revisión, el contenido del origen de la copia podría no estar fácilmente disponible. Si sospecha que tiene copias de este tipo en su repositorio, es posible que desee repensar su conjunto de rutas incluidas / excluidas, tal vez incluyendo las rutas que sirvieron como fuentes de sus operaciones de copia problemáticas también.

Esto se aplica a las migraciones / reorganizaciones que utilizan svndumpfilter. Hay momentos en los que un poco de trabajo adicional ahora puede ahorrar mucho trabajo adicional más adelante, y al mantener un uso fácil svndumpfilterdisponible para futuras migraciones / reorganizaciones, se mitiga el riesgo a un costo relativamente bajo.


¿Por qué "svn move" no sería suficiente? Su sugerencia parece aplastar una mosca con un mazo.
Rob Williams

Este comportamiento 1.4 me ha mordido: si un repositorio SVN contiene movimientos (cambios de nombre) de directorios o ramas / etiquetas, el uso de svndumpfilter para ayudar a reorganizar / migrar un repositorio a una nueva estructura puede fallar porque no maneja el historial bien. Está documentado, desenterraré la referencia. si quieres
Ken Gentle

¿Podría agregar la referencia a este comportamiento?
Jacco

2

Si bien las respuestas anteriores funcionarán, no son las mejores prácticas. El último servidor svn y el cliente se fusionan para usted. Entonces, svn sabe qué revisiones ha fusionado en una rama y de dónde. Esto ayuda mucho al mantener una rama actualizada y luego fusionarla nuevamente en el tronco.

Sin embargo, no importa qué versión de Subversion esté usando, existe un método de práctica recomendada para que los cambios de una rama vuelvan al tronco. Se describe en el manual de Subversion: Control de versiones con Subversion, Capítulo 4. Ramificación y fusión, Mantener una rama en sincronización .


Gracias por la información oficial para que pueda fusionar la rama con el tronco mediante el acercamiento oficial. La palabra clave es reintegrate
Junyo

-3

Es una configuración realmente extraña / inusual en SVN, aunque creo que está lejos de ser una "buena práctica", supongo que podrías hacer algo como:

  • Verifique todo el árbol de origen (svn co therootsourcetree)
  • Retire el tronco (svn rm trunk)
  • Copie la rama al tronco (svn cp sucursales / thebranch / trunk)
  • Eliminar la rama (svn rm ramas / thebranch)
  • Cometer los cambios

Buena suerte


9
Esto destruye el rastro de la historia que sería preservado por "svn move".
Rob Williams
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.