svn - create - Utilice Subversion sin Trunk
svn trunk (6)
Mi equipo recientemente decidió no usar la rama "troncal" que es típica de la mayoría de los diseños de repositorio subversivo. Descubrimos que en cualquier momento dado siempre había una rama particular que funcionaba en el rol tradicional que el tronco tendría en otros repositorios. 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 diseño?
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.
Nosotros - más o menos. No usamos un tronco, sino que creamos una nueva rama para cada lanzamiento de nuestros proyectos. Esta rama ''etiquetada'' 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.
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 migración 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 repositorio de subversión. Quien creó el repositorio no siguió un diseño particular: simplemente rellenó todo en la raíz del repositorio (sin tronco /, sin ramas /, y ciertamente sin etiquetas /). Quería crear una rama para trabajar y algunas etiquetas para otras cosas, pero me di cuenta de lo difícil que es hacer eso en un repositorio de subversión que no sigue un diseño adecuado.
Mi problema con el documento Perforce es que rechaza el modelo promocional sin mencionar la principal ventaja, la reducción de la sobrecarga de fusión. De hecho, el documento erróneamente establece que el "modelo principal" impone "ningún gasto administrativo adicional", un reclamo ridiculo. El modelo "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 ramas principales: una rama 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 "modelo promocional tiene problemas" es como decir "nunca use un OR / M". Depende de tu entorno
Estás hablando del modelo 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 pruebas se requieren (p. ej., deben pasar las pruebas unitarias, pruebas de regresión, prueba 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
- pruebas 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
- prueba unitaria + pruebas de regresión
- revisión de código por parte de otros 2 desarrolladores antes de confirmar
Rama de etiqueta:
- no se compromete después de la creación
Rama privada del desarrollador:
- Solo el desarrollador se registra
- Cualquier cambio
- Las pruebas solo son necesarias antes de fusionarse con el tronco
- Revisión de código antes de fusionarse con el tronco
Si tiene el modelo 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 modelo 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 obtener equipos grandes.
Si observa el desarrollo del kernel de Linux, puede ver la tensión entre el modelo de promoción y el modelo de troncal: el árbol de Linus es promocional: pasa por ciclos entre la ventana 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 árboles 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 modelo 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 función cuando la política para la línea en la que está trabajando solo cambia a las correcciones de errores, ahora necesita cambiar su copia 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 rama 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 modelo 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 ramas de características ayudan, pero tienen un costo de integración.