Sin usar Subversion Tronco

Question

Mi equipo recientemente decidió no utilizar la rama "tronco" que es típico de la mayoría de los diseños de depósito de la subversión. Hemos encontrado que en un momento dado, siempre había una rama particular que funcionaba en el papel tradicional que sostendría el tronco en otros repositorios. Es decir, siempre tenemos una rama de número más alto que representa la próxima versión que estamos trabajando. Por lo tanto, una combinación de tronco es simplemente superfluo, por lo que se deshizo de tronco.

¿Hay alguien más por ahí hacer esto?

Si es así, ¿ha notado algún pros / contras?

Incluso si su equipo no hacer esto, ¿alguien tiene alguna idea de este diseño?

Answer 1

Estamos hablando de la modelo promocional - papel de Perforce pone de relieve los problemas con él -. comunican los roles cambiantes de los códigos de líneas móviles y trabajo entre las ramas

Una expansión en mis puntos de vista de los problemas mencionados:

1) Cambio de política de código de líneas:

Cada línea de código tiene una política, ya sea por escrito y formalizado, o totalmente implícito en la cabeza de un desarrollador. Se define por ejemplo:

• quién está autorizado a comprometerse con el código línea
• Se requiere la cantidad de pruebas (Por ejemplo, hacer la unidad de pruebas tienen que pasar, pruebas de regresión, prueba del sistema completo)
• ¿cuántas personas tienen que codificar opinión cambios
• ¿qué tipo de cambios se permitido

Con el enfoque tronco, las políticas se mantienen fijas, por lo que es más probable escribir hacia abajo, lo que les hace más fácil para comunicarse (más importante en un equipo más grande).

por ejemplo. Tronco:

• cualquier desarrollador puede cometer
• cualquier cambio
• pruebas de unidad deben pasar
• revisión de código después de cometer

rama Versión:

• único desarrollador de mantenimiento
• Sólo corrección de errores
pruebas
• unidad de prueba + regresión
• revisión de código por otros 2 desarrollador antes de cometer

rama etiqueta:

• no se compromete después de la creación

rama privada del desarrollador:

• Sólo los controles de desarrolladores en
• Cualquier cambio
• Las pruebas sólo se necesita antes de fusionarse en el tronco
• La revisión de código antes de la fusión en el tronco

Si usted tiene el modelo de promoción, entonces usted tiene una póliza mientras que en el desarrollo principal, y luego tener que decirle a todo el mundo cuando se cambia la política mientras se prepara para el lanzamiento, a continuación, otra política (para la línea de código) una vez que se libera la línea.

El modelo de promoción es una tarea fácil para entrar, se asigna directamente sobre la forma de control no fuente de trabajo. Pero duele una vez que comienza a recibir los equipos grandes.

Si nos fijamos en el desarrollo del núcleo de Linux se puede ver la tensión entre el modelo y el modelo de promoción del tronco: Árbol de Linus es promocional - que pasa por ciclos entre la ventana de fusión, y el período rc / estabilización. Pero Linux siguiente y -mm han surgido para dar un aspecto más tronco como la línea.

SMC Distribuido / VCS son algo diferentes de todos modos, las políticas no tienen que ser distribuidos a todos los desarrolladores, ya que cada desarrollo tiene sus propios árboles, y saca los cambios cuando él quiere.

Los proyectos de código abierto tienen el problema de que no pueden obligar a la gente a hacer el trabajo esclavo de estabilizar un comunicado, después de la ramificación del tronco. Por tanto, el modelo de promoción es más importante como una manera de forzar a los esfuerzos de estabilización, en lugar de trabajar en características.

trabajo

2) Mover:

Un desarrollador podría estar trabajando en una característica cuando la política para la línea que está trabajando en los cambios en correcciones de errores solamente, que ahora tiene que cambiar su copia de trabajo a un código de línea diferente. Esto puede ser desde fácil a muy difícil, dependiendo del sistema de SCM en uso. Este problema no ocurre si el desarrollador está trabajando en el tronco, ya que su trabajo siempre va al tronco. Si el desarrollador está en una rama privada o función, entonces su trabajo sólo inciden en el tronco (y la liberación) en absoluto.

Si ya hay una función registró, pero se retrasa respecto a la versión que es actualmente, usted tiene que encontrar la manera de eliminarlo. Este problema todavía existente con el modelo del tronco, pero podría ser un poco más fácil de resolver - cosas cherry-picking desde el tronco de la liberación. Aquí es donde ayudan ramas de características -. Pero tienen un coste de integración

Answer 2

Mi problema con el papel Perforce es que rechaza el modelo de promoción sin mencionar la principal ventaja, reduce la fusión por encima. De hecho, el documento indica erróneamente que el "modelo de la línea principal" impone "no sobrecarga administrativa adicional", una reclamación ridiculuous. El modelo "siempre se fusionan para tronco" significa exactamente eso - usted tiene la sobrecarga de que todos tengan que fusionarse. Se trata de sobrecarga inútil si tiene la siguiente situación (que tenemos):

a) un equipo pequeño (de 5 a 7 desarrolladores) todo a tiro de uno al otro. la comunicación es un problema cuando no tenemos que hacer una rama

y

b) una base de código, donde alguna vez hay realmente solamente 2 ramas principales - una rama de producción y "lo siguiente que en el desarrollo". Tal vez en una luna azul tenemos 3.

Creo que mi punto es - es una cosa circunstancial. Decir que el "modelo de promoción tiene problemas" es como decir "nunca use un OR / M". Depende de su medio ambiente.

Answer 3

Subversion permite que ambos enfoques. El tronco no es una necesidad sino una convención. Si lo tienes, algunas herramientas de trabajo más fácilmente (por ejemplo, herramientas de migración para Git). Si no lo tiene, debe hacer algunas cosas de forma manual, pero no puedo pensar en algo que se dará cuenta durante su trabajo diario.

Answer 4

Recientemente he comenzado a trabajar en un proyecto que está en un repositorio de subversión. El que creó el repositorio no sigue ningún diseño particular, - que simplemente rellena todo en la raíz del repositorio (sin tronco /, no hay ramas / y, ciertamente, no hay etiquetas /). Quería crear una rama a trabajar y algunas etiquetas para otras cosas, pero se dio cuenta de lo difícil que es hacer eso en un repositorio de subversión que no sigue un diseño adecuado.

Answer 5

Lo hacemos - más o menos. No utilizamos un tronco, pero crear una nueva rama para cada liberación de nuestros proyectos. Esta rama 'etiquetados' es entonces el tronco para cada versión, y Backport correcciones de errores mediante la fusión de los cambios sobre la prensa anteriores.

Funciona bien para nosotros, pero tenemos una gran cantidad de sub-proyectos en nuestro proyecto.

Answer 6

IME, en algunos entornos el tronco es un buen lugar para intercambiar correcciones y cambios a / desde. Es decir, todo el mundo se fusiona sus correcciones a el tronco, y todo el mundo se fusiona correcciones de los demás de el tronco. Hemos encontrado que muy útil en un entorno donde las porciones de código se comparten entre muchos proyectos independientes y donde todos los proyectos contribuyeron al código compartido.

medio ambiente puede ser diferente, sin embargo.