¿Commite y se fusiona en subdirectorios SVN considerados dañinos?

Question

Tenemos varios subproyectos grandes dentro de nuestra raíz principal del proyecto SVN.
Comprometo y fusiono solo mi subproyecto cuando trabajo con nuestras sucursales de lanzamiento, principalmente porque es más rápido.

Sin embargo, un colega señaló este reference to merging subdirectories in Version Control with Subversion (también conocido como "El SVN libro"):

• Por ramas de liberación de larga vida (como se describe en the section called “Common Branching Patterns”), realizar combinaciones sólo en la raíz de la rama, no en subdirectorios.

Lamentablemente, este es el alcance de la advertencia. La sección vinculada tampoco da una explicación.

Está cometiendo y fusionando subdirectorios SVN perjudiciales para las ramas de publicación?
¿Qué pasa con las ramas de característica de corta duración?

Answer 1

Una posible explicación es que podría olvidarse partes de un conjunto de cambios.

Si el cambio establece que está fusionando archivos de portada que están fuera del subdirectorio que ha desprotegido, siempre existe la posibilidad de que olvide combinar esos archivos.

Por ejemplo, si tiene un compromiso de este tipo en el tronco:

r5 | rich | 2009-04-16 22:22:46 +0200 (Thu, 16 Apr 2009) | 2 lines 
Changed paths: 
    M /trunk/subdir1/main.c 
    M /trunk/subdir2/main.c 

Change some stuff 

Y luego tiene una salida de subdir1 de su rama "estable", entonces se podría fusionar el conjunto de cambios R5 como esto:

$ svn co http://example.com/svn/branches/stable/subdir1 
$ cd subdir1 
$ svn merge -c 5 http://example.com/svn/trunk/subdir1 . 
--- Merging r5 into '.': 
U main.c 
$ svn ci -m"Merged r5 from trunk" 

Pero esto sólo se fusionará la mitad de la revisión 5 Peor aún, si vas hacia atrás y observa el registro, se muestran ahora esto:

$ svn log -g http://example.com/svn/ 
... 
------------------------------------------------------------------------ 
r5 | rich | 2009-04-16 22:22:46 +0200 (Thu, 16 Apr 2009) | 2 lines 
Changed paths: 
    M /trunk/subdir1/main.c 
    M /trunk/subdir2/main.c 
Merged via: r6 

Change some stuff 

Parece que ha fusionado toda la confirmación, cuando en realidad solo ha fusionado parte de ella. Por supuesto, r6 muestra que solo 1 archivo ha cambiado en la rama estable.

------------------------------------------------------------------------ 
r6 | rich | 2009-04-16 22:28:16 +0200 (Thu, 16 Apr 2009) | 1 line 
Changed paths: 
    M /branches/stable/subdir2 
    M /branches/stable/subdir2/main.c 

Merge revision 5 from trunk 

Alguien tiene que recordar, o aviso, que sólo una parte del conjunto de cambios quedó fusionado y el resto hay que hacer. No usar fusiones de subdirectorio evita este problema.

Hay momentos en los que realmente no desea fusionar todas las confirmaciones anteriores, y la situación anterior es exactamente lo que pretendía hacer. En ese caso, probablemente sea mejor agregar un buen mensaje de compromiso que describa sus intenciones.

Answer 2

El compromiso no debería tener un problema, pero en las fusiones SVN rastrea qué es y qué no se fusiona.

Por lo tanto, supongo que desea fusionarse en la raíz para simplificar las fusiones futuras (con respecto al tamaño del conjunto de datos que se compara con SVN).

Answer 3

Para las versiones de subversión anteriores a la 1.5, la fusión de subdirectorios realizada más tarde se complica con fusiones del resto del árbol de directorios. Si fusionó un directorio, svn simplemente aplicó todos los cambios realizados en ese directorio a la otra rama.Si ya había combinado un subdirectorio y luego intentado fusionar el directorio principal, todos los cambios en el subdirectorio ya estaban en la rama de destino (ya que los fusionó antes). Svn ahora no sabía que estos cambios eran de una combinación anterior, solo vio que había cosas "en el camino" cuando se trató de fusionar el subdirectorio, lo que generó muchos conflictos.

Para evitar esto, habría tenido que tener cuidado de fusionar únicamente los directorios que no se había fusionado anteriormente, haciendo que todo el proceso sea mucho más complicado. Debía recordar exactamente qué revisiones de qué subdirectorios ya había fusionado y solo aplicar los cambios restantes de los directorios/revisiones restantes. Esto puede ser confuso. Siempre fusionar toda la rama hizo esto mucho más fácil. Las versiones actuales de subversión hacen un seguimiento de las fusiones previas internamente, de modo que estos problemas pueden evitarse.

La comisión de subdirectorios no es un problema. Para svn esto es solo una revisión normal y global del repositorio. En esa revisión solo habrá cambios en un subdirectorio, pero para svn sigue siendo una nueva versión de todo el repositorio, al igual que cualquier otra confirmación.

Answer 4

Otra razón para esto podría ser que al fusionarse solo con la raíz se limita el número de propiedades de svn: mergeinfo que se establecerán en las carpetas/archivos de su repositorio.