svn - update - ¿Cuándo es realmente necesaria la opción de reintegración?

tortoisesvn 1.9 5.27581 x64 svn 1.9 5

Question

Si siempre sincronizas una rama de características antes de fusionarla. ¿Por qué realmente tienes que usar la opción --reintegrate ?

El libro de Subversion dice:

Sin embargo, al fusionar tu rama con el tronco, las matemáticas subyacentes son bastante diferentes. Su rama de características ahora es una mezcla de cambios de troncales duplicados y cambios de ramas privadas, por lo que no hay un rango contiguo simple de revisiones para copiar. Al especificar la opción --reintegrar, le está pidiendo a Subversion que replique cuidadosamente solo los cambios exclusivos de su rama. (Y, de hecho, lo hace comparando el último árbol de troncales con el último árbol de ramas: ¡la diferencia resultante es exactamente lo que cambia tu rama!)

Por lo tanto, la opción --reintegrate solo fusiona los cambios que son exclusivos de la rama de la característica. Pero si siempre se sincroniza antes de fusionar (lo cual es una práctica recomendada, para lidiar con cualquier conflicto en la rama de características), entonces los únicos cambios entre las ramas son los cambios que son exclusivos de la rama de características, ¿verdad? Y si Subversion intenta fusionar el código que ya está en la rama de destino, simplemente no hará nada, ¿verdad?

En una entrada de blog , Mark Phippard escribe:

Si incluimos esas revisiones sincronizadas, entonces fusionamos los cambios que ya existen en el tronco. Esto produce conflictos innecesarios y confusos.

¿Hay algún ejemplo de cuándo abandonar la reintegración me da conflictos innecesarios?

Answer 1

Creo que Mark significa que evita comparar dos archivos que se han modificado, uno para reintegrarse desde la rama y su archivo correspondiente en el tronco, cuando ambos se han sincronizado (y no solo se han cambiado localmente en sus respectivas ramas).

Supongamos que tenemos trunk/ac y branches/dev/ac , con trunk/ac modificado en algún punto y reintegrado en la rama más adelante con una combinación. Como señalaste, es una buena práctica hacer eso antes de volver a poner todo en el maletero.

Entonces, el siguiente paso sería volver a unirse al tronco, donde ac son "diferentes" en ambos lados, ya que han cambiado en ambos lugares. Sin la opción, habrá una comparación innecesaria, cuando la --reintegrate hará que SVN vea que el cambio no fue solo local.

Answer 2

Déjame explicarte cuando --reintegrate es absolutamente necesario.

Considere el siguiente caso de uso.

1. tienes proyecto p1 bajo p1 / tronco . El proyecto tiene un archivo, readme.txt , con una línea "line1" <
2. Crear una nueva rama, p1 / ramas / br1
3. Quédate en el maletero. Agregue la línea "line2" a readme.txt y readme.txt en el tronco
4. Cambie a la rama p1/branches/br1 branch p1/branches/br1 . Actualización a HEAD.
5. Combinar desde el tronco a esta rama (para recoger los cambios del tronco).
6. Deberías tener line1 y line1 en readme.txt
7. Confirmar fusionar el resultado con p1/branches/br1 rama
8. Cambiar al maletero. Actualización a HEAD.
9. Combinar desde p1/branches/br1 to trunk.
   1. Verás line1 , line1 y line2 en readme.txt . Entonces, tienes "line2" dos veces, lo cual es incorrecto. SVN no muestra ningún conflicto. Por lo tanto, es muy peligroso porque la combinación se realiza sin errores y tiene la impresión de que todo está bien.

La solución aquí es que la fusión del paso 9 se debe realizar utilizando la opción --reintegrate . La opción de reintegrar le dice a SVN que compare br1 con el troncal y aplique solo los cambios br1 al troncal. En este caso particular no hemos hecho ningún cambio en br1 . El resultado en el troncal debe ser dos líneas "línea1" y "línea2".

Otra observación útil. La rama p1/branches/br1 ya no debe usarse para el desarrollo después del paso 9. Si desea continuar con el desarrollo en sucursales, cree una nueva, por ejemplo, p1/branches/br2 . Otra fusión del tronco a p1/branches/br1 causa muchos conflictos.

Answer 3

Nunca es necesario usar --reintegrate - es simplemente un alias. Si tiene una copia de trabajo del trunk , entonces

svn merge --reintegrate url://feature-branch workingcopy

es lo mismo que

svn merge url://trunk url://feature-branch workingcopy

Puedes usar el que te sea más cómodo.

Answer 4

Nunca es necesario usar --reintegrate ; es una conveniencia Si su combinación más reciente de trunk a feature-branch combinó todos los cambios que ocurrieron en el trunk desde que se ramificó hasta la revisión de revisión, entonces podría usar el siguiente comando.

svn merge url://trunk@rev url://feature-branch .

Tenga en cuenta que este comando se ejecutará en la raíz de una copia de trabajo actualizada de la trunk sin que se confirmen cambios pendientes.

Permítame expandir mi respuesta para responder más directamente a la pregunta "¿Existe un ejemplo de cuándo abandonar la reintegración me da conflictos innecesarios?"

Esto es lo que significa el artículo con "Si incluimos esas revisiones sincronizadas, luego fusionamos los cambios que ya existen en el tronco. Esto genera conflictos innecesarios y confusos".

Incluyendo las revisiones sincronizadas se vería así:

svn merge -r N:HEAD url://feature-branch .

Donde es una copia de trabajo limpia del tronco y N es la revisión que feature-branch se creó a partir del trunk . Ese comando de combinación combina todos los cambios confirmados en la feature-branch desde que se ramificó, incluidos los cambios que se fusionaron desde el trunk después feature-branch se creó la feature-branch . Eso significa que los cambios ya realizados en el trunk se incluirían en la combinación anterior. Le estaría diciendo a Subversion que aplique los cambios al trunk que realmente se originaron en el trunk , lo que resulta en conflictos.