Subversion: eliminando viejas ramas de características en lugar de mantenerlas

Question

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 hará que sea más difícil realizar un seguimiento de qué ramas existían, especialmente cuando los nombres potencialmente duplicados entran en el escenario (digamos que buscamos refactorizar dos veces), sus historias de compromiso desaparecen en algún lugar del profundidad del repositorio, etc.

Por otro lado, las ramas se usan 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 en.

¿Cuáles son los pros y contras que me falta? ¿Qué están haciendo las personas?

Answer 1

Si realmente está preocupado por eliminarlos, para que no se olviden, simplemente cree una carpeta en las ramas llamadas 'inactivas' y svn move sus ramas inactivas más antiguas en esa carpeta. Esto podría ser lo mejor de ambos mundos para ti.

Answer 2

Puede 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.

Answer 3

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 puede encontrar una sucursal, le recomendamos que use la bandera -rrevision en su log/diff/checkout/lo que generalmente es todo lo que necesita.

Answer 4

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 cometieron 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.