Utilice Subversion sin Trunk

Mi equipo recientemente decidió no usar la twig "troncal" que es típica de la mayoría de los layouts de repository subversivo. Descubrimos que en cualquier momento dado siempre había una twig particular que funcionaba en el rol tradicional que el tronco tendría en otros repositorys. Es decir, siempre tenemos una sucursal con el número más alto que representa la próxima versión en la que estamos trabajando. Por lo tanto, una fusión al tronco es simplemente superflua, así que nos deshicimos del tronco.

¿Alguien más por ahí hace esto?

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

Incluso si su equipo no hace esto, ¿alguien tiene alguna idea sobre este layout?

Estás hablando del model promocional – el documento de Perforce resalta los problemas que presenta – comunicando los roles cambiantes de las líneas de código y moviendo el trabajo entre sucursales.

Una expansión en mi visión de los problemas enumerados:

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

Cada línea de código tiene una política, ya sea escrita y formalizada, o completamente implícita en la cabeza de un desarrollador. Define, por ejemplo:

  • quién puede comprometerse con la línea de código
  • cuántas testings se requieren (p. ej., deben pasar las testings unitarias, testings de regresión, testing completa del sistema)
  • cuántas personas tienen que codificar los cambios de revisión
  • qué tipo de cambios se permiten

Con el enfoque troncal, las políticas permanecen fijas, por lo que son más fáciles de anotar, lo que facilita la comunicación (más importante en un equipo más grande).

por ejemplo, Tronco:

  • cualquier desarrollador puede comprometer
  • cualquier cambio
  • testings unitarias deben pasar
  • revisión del código después del commit

Rama de la versión:

  • solo desarrollador de mantenimiento
  • solo corrección de errores
  • testing unitaria + testings de regresión
  • revisión de código por parte de otros 2 desarrolladores antes de confirmar

Rama de label:

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

Rama privada del desarrollador:

  • Solo el desarrollador se registra
  • Cualquier cambio
  • Las testings solo son necesarias antes de fusionarse con el tronco
  • Revisión de código antes de fusionarse con el tronco

Si tiene el model de promoción, entonces tiene una política mientras está en desarrollo principal, luego debe informar a todos cuándo cambia la política mientras se prepara para la publicación, luego otra política (para la línea de código) una vez que se libere la línea.

El model de promoción es fácil de ingresar, se asigna directamente al modo de trabajo de control que no es fuente. Pero duele una vez que comienzas a get equipos grandes.

Si observa el desarrollo del kernel de Linux, puede ver la tensión entre el model de promoción y el model de troncal: el tree de Linus es promocional: pasa por ciclos entre la window de fusión y el período de estabilización / rc. Pero Linux-next y -mm han surgido para dar una línea más troncal.

De todos modos, los SCM / VCS distribuidos son algo diferentes, las políticas no tienen que distribuirse a todos los desarrolladores porque cada uno tiene sus propios treees y realiza cambios cuando lo desea.

Los proyectos de código abierto adolecen del problema de que no pueden obligar a las personas a realizar el trabajo de estabilización de un lanzamiento, luego de ramificarse desde el tronco. Por lo tanto, el model de promoción es más importante como una forma de forzar los esfuerzos de estabilización, en lugar de solo trabajar en las características.

2) Trabajo en movimiento:

Un desarrollador puede estar trabajando en una function cuando la política para la línea en la que está trabajando solo cambia a las correcciones de errores, ahora necesita cambiar su copy de trabajo a una línea de código diferente. Esto puede ser de fácil a extremadamente difícil dependiendo del sistema SCM en uso. Este problema no ocurre si el desarrollador está trabajando en el tronco, ya que su trabajo siempre va a la troncal. Si el desarrollador se encuentra en una twig privada o característica, entonces su trabajo solo afectará a la troncal (y la versión) en absoluto.

Si una característica ya está registrada, pero se retrasa con respecto a la versión en la que se encuentra actualmente, debe averiguar cómo eliminarla. Este problema aún existe con el model de troncales, pero podría ser un poco más fácil de resolver: recoger cosas del tronco para el lanzamiento. Aquí es donde las twigs de características ayudan, pero tienen un costo de integración.

Mi problema con el documento Perforce es que rechaza el model promocional sin mencionar la principal ventaja, la networkingucción de la sobrecarga de fusión. De hecho, el documento erróneamente establece que el "model principal" impone "ningún gasto administrativo adicional", un reclamo ridiculo. El model "fusionarse siempre con el maletero" significa exactamente eso: usted tiene la responsabilidad de que todos tengan que fusionarse. Esto es una sobrecarga sin sentido si tiene la siguiente situación (que tenemos):

a) un pequeño equipo (de 5 a 7 desarrolladores) todos a una distancia de gritos el uno del otro. la comunicación no es un problema cuando necesitamos hacer una sucursal

y

b) una base de código donde en realidad solo hay 2 twigs principales: una twig de producción y "lo siguiente en desarrollo". Quizás una vez en una luna azul tenemos 3.

Creo que mi punto es que es algo situacional. Decir que el "model promocional tiene problemas" es como decir "nunca use un OR / M". Depende de tu entorno

Subversion permite ambos enfoques. El maletero no es una necesidad sino una convención. Si lo tiene, algunas herramientas funcionan más fácilmente (por ejemplo, herramientas de migration para Git). Si no lo tiene, debe hacer algunas cosas manualmente, pero no puedo pensar en algo que notará durante su trabajo diario.

Recientemente comencé a trabajar en un proyecto que está en un repository de subversión. Quien creó el repository no siguió un layout particular: simplemente rellenó todo en la raíz del repository (sin tronco /, sin twigs /, y ciertamente sin tags /). Quería crear una twig para trabajar y algunas tags para otras cosas, pero me di count de lo difícil que es hacer eso en un repository de subversión que no sigue un layout adecuado.

Nosotros – más o less. No usamos un tronco, sino que creamos una nueva twig para cada lanzamiento de nuestros proyectos. Esta twig 'labelda' es entonces la troncal de cada versión, y respaldamos las correcciones de errores fusionando los cambios en las versiones anteriores.

Funciona bien para nosotros, pero tenemos muchos subproyectos en nuestro proyecto.

IME, en algunos entornos, el tronco es un buen lugar para intercambiar correcciones y cambios desde / hacia. Es decir, todos fusionan sus soluciones con el baúl, y todos combinan las soluciones de otros desde el baúl. Descubrimos que era muy útil en un entorno en el que se compartían muchos códigos entre muchos proyectos independientes y donde todos esos proyectos contribuían al código compartido.

Sin embargo, tu entorno puede ser diferente.