software - mercurial svn

¿Repositorios mercuriales con muchos desarrolladores activos? (2)

Estoy revisando Bitbucket y parece que no puedo encontrar ningún repositorio de Mercurial que se parezca a lo que sospecho que sería nuestro repositorio, siempre que cambiemos a Mercurial.

Como tal, me pregunto, ¿hay un flujo de trabajo que no estemos considerando aquí?

De lo que estoy hablando es de que hice una pequeña prueba automatizada. Somos 14 personas que trabajamos en el mismo proyecto, divididas en 4 equipos de scrum. Para simular 14 personas (elegí 10, número redondo) que trabajan en paralelo en el código, usando Mercurial DVCS, presionando hacia el mismo repositorio central central, escribí un script.

Creé un nuevo repositorio "maestro", y luego lo cloné para 10 personas virtuales
Luego ejecuté un bucle de 1000 iteraciones, seleccionando un clon aleatorio y realizando una de las siguientes acciones:
- 10% de las veces, realice una extracción desde el maestro, fusione, confirme la combinación y presione
- El 90% del tiempo, hacer un cambio local y comprometerse.

Tenga en cuenta que me aseguré de que nunca habría conflictos de fusión simplemente haciendo que cada persona virtual trabaje en su propio archivo.

Esto simularía a las personas que trabajan localmente haciendo comillas 1+ antes de jalar, fusionar y empujar (para evitar más de 2 cabezas en el repositorio principal). Puede ser que este flujo de trabajo sea incorrecto.

Esta es una muestra de cómo se ve el repositorio ahora (captura de pantalla + enlace a repo):

El repositorio se puede encontrar aquí: http://hg.vkarlsen.no/hgweb.cgi/parallel_test/graph .

Esto parece terriblemente desordenado, y como dije, parece que no puedo encontrar ningún repositorio que tenga un historial similar. Por "desordenado", quiero decir que parece que la historia más antigua del proyecto casi siempre tendrá 10 sucursales paralelas. Por supuesto, cerca de la parte superior, se reduce, pero se expandirá a medida que las personas que actualmente están trabajando en su repositorio local empujen al maestro.

Así que tengo dos preguntas:

¿Puede alguien mostrarme un repositorio que tenga una historia similar? Como parece que no puedo encontrar ninguna, estoy empezando a preguntarme qué tipo de conclusiones puedo sacar de eso ...
¿Hay algún problema con nuestro flujo de trabajo (es decir, el flujo de trabajo que he presentado aquí)? ¿Deberíamos cambiar de base / aplastar / trasplantar, delegar la responsabilidad en una persona, otras cosas, en lugar de la forma en que se hizo aquí?

Impresionante preparación!

Siempre se ve desordenado si regresa un poco y mira todas las confirmaciones antiguas al mismo tiempo. Siempre va disminuyendo, incluso mirando un poco la historia antigua. Consulte http://hg.intevation.org/mercurial/crew/graph/12402?revcount=120 por ejemplo. Este no es el compromiso más reciente, pero muestra todo el historial hasta ese compromiso.
Rebase ayuda bastante, especialmente si las personas están trabajando en áreas separadas. (Por lo general, verifico las confirmaciones entrantes para ver si hay posibles conflictos de archivos o de funcionalidad, y si no es así, hago rebase).

Sin embargo, Rebase no es infalible, así que fusionar es la acción "segura" preferida, pero deja más "basura" en la historia. Una compensación.

Rebase es algo así como la actualización estándar SVN bog. El material existente está hecho de referencia y sus cambios van más arriba, cruzando los dedos todavía funciona. Es útil, pero hay ocasiones en las que te sientes más seguro al tener el tuyo, el de ellos y la combinación como compromisos separados en la historia.

También hay una opción de squashing de compromiso (tal vez una extensión de histedit), que aplasta todos los commit intermedios de uno. Esto es útil cuando está a punto de presionar y desea transferir muchos compromisos parciales en su propio repositorio como un solo compromiso con el principal.

Tengo 12 desarrolladores trabajando en el mismo repositorio de Mercurial en el trabajo, y nuestra historia no se parece en nada a eso. Hay compromisos de combinación ocasionales, pero la mayoría de las combinaciones se deben a la combinación de sucursales reales, es decir, podría haber una fusión en nuestra rama de desarrollo principal que traiga cambios de una versión de corrección de errores realizada en la rama de producción / lanzamiento.

Esto es muy fácil de lograr, los desarrolladores piratean y se comprometen con su repositorio local y cuando tienen algo lo suficientemente estable como para compartir con el resto del equipo que presionan.

Si no se ha cometido nada desde que comenzaron a cometer, el empuje pasa sin problemas.

Si alguien más ha cometido un cambio, Mercurial se queja de que el impulso creará cabezas remotas. El desarrollador entonces hace un hg pull --rebase y hg pull --rebase el push. El empuje pasa y todos están contentos.

Si está utilizando la integración continua con los desarrolladores presionando regularmente a un repositorio compartido, este es el camino a seguir. Saber si ha impulsado cambios o no es fácil y evita muchas confusiones inútiles de confusiones que saturan su historial.