svn - create - Subversión: borrar viejas ramas de características vs. mantenerlas
tortoise svn (4)
He estado eliminando ramas de características cuando terminamos, ya que me gusta la falta de desorden. Ha habido una pequeña confusión por parte de otros desarrolladores, pero desde que registramos los números de revisión de confirmaciones en nuestro sistema de seguimiento de errores, ha sido bastante sencillo. Si alguien viene diciendo que no pueden encontrar una sucursal, los consejos para usar la bandera de -rrevision en su log / diff / checkout / lo que sea generalmente es todo lo que se necesita.
Tengo un repositorio de subversión con el diseño estándar, es decir, trunk / y branches / (y tags /). Cuando se trabaja en un cambio mayor, se usa una rama de características, se sincroniza regularmente con el tronco y luego se vuelve a integrar en el tronco (usando 1.5 ahora). Bastante estándar.
Lo que me pregunto es si dicha rama de características, una vez finalizada y fusionada, debería mantenerse o borrarse. El libro de subversión ocasionalmente parece sugerir que es común eliminarlos, pero también he visto un montón de proyectos de código abierto que mantienen las sucursales.
También estoy algo preocupado acerca de cómo eliminar una rama dificulta hacer un seguimiento de qué ramas existían, especialmente cuando los nombres potencialmente duplicados ingresan al escenario (digamos que buscamos-refactorizar dos veces), sus historias de compromiso desaparecen en algún lugar en la profundidad del repositorio etc.
Por otro lado, las ramas se utilizan bastante, especialmente con 1.5 ahora, y me gusta la idea de no tener que buscar en una gran lista de ramas inactivas para encontrar las que estoy trabajando actualmente.
¿Cuáles son los pros y contras que me estoy perdiendo? ¿Qué están haciendo las personas?
Mi equipo los elimina para mantener el desorden. No es como irse después de todo; se pueden recuperar si se desea. Tiene razón en que puede ser difícil encontrarlos de nuevo: necesita saber un número de revisión donde existía la rama, por lo que le dice a su cliente que mire esa revisión para ver sus archivos.
Usamos FogBugz para nuestra gestión de proyectos, que realiza un seguimiento de cuándo se comprometieron las cosas en nuestro repositorio SVN por número de revisión. Podemos usar esto para determinar a qué revisión debemos revertir para ver nuestros archivos: encontramos el historial de características en FogBugz, buscamos para determinar en qué revisiones existió la rama y usamos esa información para saltar hacia atrás.
Puedes eliminarlos de forma segura. Al eliminarlos no se eliminan del repositorio, el espacio asignado nunca se recupera, pero seguro que hace que todo el árbol del proyecto se vea más limpio.
Si realmente está preocupado por eliminarlos, para que no se olviden, simplemente cree una carpeta bajo las ramas llamada ''inactiva'' y svn move sus ramas anteriores e inactivas a esa carpeta. Esto podría ser lo mejor de ambos mundos para ti.