El uso de troncales / Ramas y estructura de etiquetas entre varios desarrolladores

Question

I terminan siendo confundidos cuando se trata de trunk / ramas y etiquetas. Lo que sigue es mi consulta:

Tenemos un equipo de desarrolladores que trabajan en un mismo proyecto. Los desarrolladores a menudo se dividen en grupos y trabajan en varios módulos en el mismo proyecto.

En la actualidad, tenemos un sistema de SVN sencilla (sin ningún tipo de troncal / Ramas o etiquetas) donde todos trabajan en el mismo servidor local y compromete a los archivos. Pero el problema comienza cuando, un par de desarrolladores trabajar en módulos futuros (que no se supone que ir a vivir inmediatamente). En esta situación, no pueden comprometer los datos, ya que si lo hacen, su código de desarrollo será cargado en el servidor en vivo y que va a terminar arruinando todo.

Así pues, ahora estoy en busca de algún tipo de solución en la que, estos desarrolladores pueden trabajar por separado, pero en el mismo código. Algo como esto:

Un desarrollador está trabajando en Nueva Módulo A El desarrollador B está trabajando en Nueva Módulo B Desarrollador C está trabajando en Corrección de errores del módulo C (que ya está en las necesidades de insectos vivos, pero pocos que se fija)

Así, desarrollador A tendrá su propia copia en esta máquina y se comprometerá a repositorio desarrollador de una. (O rama)

La misma lógica se aplica a desarrollador B, pero desarrollador C estarán trabajando en una copia común estable que estará en algún lugar de las etiquetas y una vez que el trabajo está hecho, será etiquetado y empujó al tronco para la carga en el servidor en vivo.

Una vez desarrollador A se realiza con el trabajo, que presionará todos sus archivos de tronco para la carga en vivo. (Esto debería combinar algunos archivos comunes en el tronco también). La misma lógica se aplica a desarrollador B.

No estoy seguro de si SVN será la solución adecuada para esto o no. Ni siquiera sé si hay alguna manera más sencilla de poner en práctica lo que quiero.

Cualquier tipo de sugerencias son bienvenidos.

Gracias TTR

Answer 1

En primer lugar mi opinión es que si todos los desarrolladores están trabajando en piezas separadas del proyecto, a continuación, puede acabar con ramas. Se puede tomar un poco de organización (por ejemplo, comentarios de registro adecuados y control de versiones), pero que puede ser muchos menos problemas que ramas y la mezcla.

Ok, pero si lo hace ramas queremos, que son fáciles. Hay varios enfoques para esto, pero básicamente todos implican una versión de 'maestro' en el que el código final termina. esto puede ser el tronco, o algunas personas prefieren hacer cambios en el tronco y luego fusionar el código de liberación a las sucursales. El 'tronco es maestra' es el concepto más fácil de entender sin embargo.

En SVN, por lo que una rama es fácil - es una copia barata por lo que su único problema está llenando un directorio con las cosas (recomiendo la eliminación de una rama, una vez que haya terminado con él). SVN le da un tipo especial de rama para este tipo de trabajo también - la rama reintegración . Es especial como pistas SVN lo que le sucede, su proyectados de manera que se crea una rama desde el tronco, trabajar en él, de vez en cuando su actualización con los cambios que se han hecho en el tronco, y luego reintegrar a todo su trabajo en esa rama en el tronco en una explosión final. A continuación, puede empezar todo de nuevo. Suena como esto podría ser lo que quiera - por lo general, sin embargo, que no tendría una rama por desarrollador, que tendría una rama para cada paquete de trabajo.

El problema con ramificaciones por-dev es que como una rama vive más tiempo y más tiempo, los cambios que hacen será más difícil y más difícil de volver de mezcla. Esto es especialmente cierto si los desarrolladores no se combinan el trabajo del otro dev en sus ramas con regularidad (como lo suelen hacer).

Como SVN hace copias baratas, que probablemente recomendaría ramificación de todo el tronco para cada desarrollador. Me parece que es más fácil de recordar que en lugar de ramificación directorios individuales, y siempre seré capaz de cambiar los archivos compartidos o comunes sin tener que preocuparse si la comisión de ellos se romperán una rama diferente. (Es decir, si se ramifican / trunk / moduleA y más tarde encuentra que necesita al cambio / trunk / include / common_file entonces el archivo común no estará en su rama a medida que bifurcó un sub-conjunto. Así que sólo la rama en la raíz como Eso no t le costará ningún extra)

Answer 2

En su pregunta, que acaba expresaron la razón fundamental detrás de todo el modelo del tronco / tags / ramas - es para administrar exactamente esta situación, que es una situación normal para un taller de desarrollo para llegar a después de un corto periodo de tiempo <. / p>

Una cosa a su plan es la migración de un modelo sin tronco a tronco de un modelo.

Usted dice que no tiene ningún tronco, etiquetas, ramas, etc Así que supongo que su apariencia modelo algo como esto:

/
 filea.html
 fileb.html
 dira/
  filex

Una palabra de advertencia -. no trate de ramificar el directorio raíz debajo de sí mismo

por ejemplo:

svn cp / /branchA

Esto resultaría en un directorio que se parece a:

/
 filea.html
 fileb.html
 dira/
  filex
 branchA/
  ...
 branchB/
  ...

Desgrapado lo que es una parte de la rama de la raíz y las subramas se vuelve bastante intratable con bastante rapidez.

Manténgalo limpio - mover todo el código en el tronco en primer lugar. Este es el tipo de salto estructural que requerirá todo el mundo (y todos sus sistemas de despliegue) para borrar sus espacios de trabajo y conseguir todo de limpieza:

svn cp / /trunk

ahora usted puede hacer sus ramas:

svn cp /trunk /branches/branchA

Dándole una estructura como:

/
 trunk/
  filea.html
  fileb.html
  dira/
   filex
 branches/
  branchA/
   ...

Una vez que se han hecho las ramas, los de Dev puede comprobar a cabo y trabajar en ellos. Su sistema de despliegue puede señalar tronco / en lugar de la carpeta raíz e implementarla.

Cualquier desarrolladores que trabajan en correcciones de errores puede comprobación tronco. Cuando se comprometen, el sistema de despliegue desplegará sus cambios al igual que lo hacen ahora.

Cuando branchA es terminado, los desarrolladores pueden combinar los cambios en el tronco del mismo modo gbjbaanb sugiere.

Sólo una rápida mano a mano, buena suerte con él.