Uso de troncos, twigs y tags en un proyecto

Conozco la teoría, pero ¿cómo se usa svn desde un punto de vista práctico para un proyecto? Diga, tengo un website con funciones que se modificarán o agregarán. ¿En qué casos se usarían nuevos troncos, twigs y tags?

Diferentes organizaciones hacen cosas muy diferentes. La solución que Alex da más arriba es común, sin embargo, se encuentra con el problema de que solo descubrirá qué otras twigs tienen conflictos con las suyas después de que aterrice su sucursal. Esto hace que las personas tengan que depurar conflictos en cosas que no han visto en algún momento.

El otro enfoque común que he encontrado es hacer todo el desarrollo en trunk, y hacer que los desarrolladores hagan commits pequeños, independientes, commits. Hay una variedad de forms de agregar una característica y hacerla invisible por defecto, pero activada en su copy de desarrollo. Usalos, usalos a ellos. Este enfoque requiere la atención de los desarrolladores, pero evita el dolor de la gestión de conflictos entre twigs de mayor duración.

Muchas de las personas que usan la solución de Alex saltan y dicen: "¡Eso nunca funcionará para nada más allá de un pequeño equipo!" A eso respondo que no hay nada de malo en los equipos pequeños, su productividad generalmente excede por mucho a cualquier cosa que pueda hacer un equipo grande. Y esa estrategia puede escalar si los desarrolladores tienen disciplina, por ejemplo, Google la usa. Si desea ver un proyecto real que utiliza esa estrategia, consulte http://llvm.org/ .

Y algunos consejos. Si quieres seguir la estrategia de Alex, te recomiendo usar git en lugar de svn. Maneja twigs mucho mejor que svn. Si desea seguir la estrategia que sugiero y su equipo no es un equipo pequeño con personas de su confianza, debe utilizar una herramienta de revisión de código como http://code.google.com/appengine/articles/rietveld.html para networkingucir los problemas obvios que pueden popup.

Eche un vistazo a estos dos artículos:

http://www.snuffybear.com/ucm_branch.htm

http://www.vance.com/steve/perforce/Branching_Strategies.html

El enlace de SnuffyBear habla más sobre la estrategia que parece querer emplear, mientras que el otro artículo habla sobre otras estrategias, como la publicación por publicación. Cada artículo describe las ventajas y desventajas de cada estrategia.

Yo diría que un solo tronco donde se hacen cambios "menores" estables (tal vez pequeñas correcciones de errores), no romperán su construcción.

Las sucursales se deben hacer para nuevas características / grandes cambios. La twig debe mantenerse actualizada con los cambios en su tronco, mientras la twig esté en funcionamiento.

Una vez que se haya completado su nueva function, la twig se debe fusionar de nuevo en el tronco y luego se puede eliminar la twig.

Las tags son para lanzamientos. por ejemplo, v1.2

Mis humildes observaciones: fusionar twigs es aterrador. En muchos casos, los cambios realizados por diferentes desarrolladores están completamente separados y se fusionan sin problemas. Pero en cualquier proyecto ocupado, habrá ocasiones en que los cambios entren en conflicto. Si tiene suerte, SVN reconoce el conflicto y le da errores en el momento de la fusión. Si tiene less suerte, SVN no lo detecta pero no comstack. De cualquier manera, alguien ahora tiene que descubrir cómo armar los cambios. A veces esto es obvio y fácil. Pero muchas veces he tenido que recurrir a los desarrolladores que realizaron los cambios para que pudiéramos decidir qué hacer.

Si tiene mucha mala suerte, ni SVN ni el comstackdor ven un problema, los cambios conflictivos pasan a producción y el progtwig se comporta de manera incorrecta.

A partir de esta observación, llego a dos conclusiones: (a) Haga tan pocas twigs como sea posible. O más exactamente, desarrolle su estrategia para hacer la menor cantidad de fusiones posible. Y (b) Se fusiona con el código mientras todavía está en testing.

Por un time, mi empresa tuvo una estrategia de ramificación que decía que cada proyecto tenía su propia twig, probada fuera de esa twig, y ​​cuando estábamos listos para implementarla en producción, fusionamos todas las twigs para ser incluidas en esa versión, comstackdas e implementadas . Esta resultó ser una muy mala idea. Alguien intentará resolver los conflictos de combinación el día anterior al deployment, y los resultados de la fusión nunca se probaron. Una gran cantidad de errores sutiles se deslizó en la producción.

Para un whlie usamos esta estrategia: la mayoría del desarrollo se hace en tronco. Cuando un lanzamiento está listo para ser entregado al grupo de testing, le quitamos una twig. Luego, trabaje en la próxima versión que procede en el enlace troncal. Cualquier corrección de errores a la versión actual se realiza en la twig, y ​​los cambios en esta twig se fusionan periódicamente en la línea troncal. Ocasionalmente, era necesario tener trabajo en 3 lanzamientos que se realizaban simultáneamente, es decir, una versión estaba en testing, otra estaba a punto de estar list para la testing, y ahora tenemos que comenzar la próxima versión. En ese caso, tendríamos la twig de testing, el tronco para la versión actual y una twig "pre" para la próxima versión. Cuando el lanzamiento actual fue para el grupo de testing, fusionamos la twig "pre" en trunk y se convirtió en la versión actual.

Recientemente hemos comenzado a experimentar con una estrategia ligeramente diferente. Cuando un lanzamiento se encuentra en fase de testing, aún le quitamos una twig separada. Pero las correcciones que surgen de las testings se realizan en el tronco, y luego esas correcciones se combinan desde el tronco a la twig de testing. Esto significa que todo el desarrollo ocurre en el tronco, y las fusiones siempre son del tronco a otro lugar. Esto tiene dos grandes ventajas: una, los desarrolladores siempre están probando con trunk, por lo que confiamos más en que el código en trunk es bueno. El grupo de testing realizará una testing con respecto a la twig de publicación, por lo que confiamos en que la twig de publicación sea buena. Es decir, tenemos cierta confianza de que ambas twigs serán probadas. Cuando realiza cambios en una bifurcación y luego se fusiona de nuevo con el enlace troncal. hay poca security de que alguien pruebe los resultados de esa fusión. Dos, el tronco siempre tiene la historia completa de "culpa" de cada module. Cuando se fusiona de las twigs al tronco. la historia en attributes de troncales cambia de la twig a la persona que hizo la fusión, en lugar de la persona que realmente hizo el cambio, y el comentario tiende a ser un desinformativo "fusionado de brach xyz". Cuando se fusiona de troncal a una twig, asegúrese de que la twig ahora muestra la persona "incorrecta" y un comentario no informativo, pero el tronco tiene un buen historial. Hay un lugar a donde ir para la historia en vez de tratar de perseguir twigs.