repositorios mercuriales con muchos desarrolladores activos?

Question

Estoy pasando por Bitbucket y parece que no puedo encontrar ningún repositorio Mercurial que se parezca a lo que sospecho que se vería en nuestro repositorio, siempre que cambiemos a Mercurial.

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

Lo que estoy diciendo es que hice una pequeña prueba automatizada. Somos 14 personas que trabajamos en el mismo proyecto, divididos en 4 equipos scrum. Para simular 14 (elegí 10, número redondo) personas que trabajan en paralelo en el código, usando Mercurial DVCS, presionando al mismo repositorio principal central, escribí un guión.

1. he creado un nuevo repositorio "maestro", y luego clonado para 10 personas virtuales
2. Entonces me encontré con un bucle 1000 iteración, la selección de un clon de azar, y una de las acciones siguientes:
   • 10% del tiempo, hacer un tirón de maestro, fusionar, cometer de mezcla, y empuje
   • 90% del tiempo, hacer un cambio local y cometer

Tenga en cuenta que me aseguré de que nunca hubiera 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 1+ confirmaciones antes de tirar, fusionar y empujar (para evitar 2 encabezados en el repositorio maestro). Es posible que este flujo de trabajo sea incorrecto.

Esta es una muestra de lo que el repositorio ahora se ve como (+ pantalla enlace a la cesión temporal):

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

Esto se ve muy complicado, y como he dicho, parece que no puedo encontrar repositorios que tengan un historial similar. Por "desordenado", quiero decir que parece que la historia anterior del proyecto casi siempre tendrá 10 sucursales paralelas. Cerca de la parte superior, se reduce, por supuesto, pero se expandirá a medida que las personas que trabajan actualmente en su repositorio local presionen al maestro.

así que tengo dos preguntas:

1. ¿Alguien puede mostrar un repositorio que tiene una historia similar? Como parece que no puedo encontrar ninguno, me estoy empezando a preguntar sobre qué tipo de conclusiones puedo sacar de eso ...
2. ¿Hay algún problema con nuestro flujo de trabajo (es decir, el flujo de trabajo que he expuesto? aquí)? ¿Deberíamos volver a basar/aplastar/trasplantar, delegar responsabilidad de empuje a una persona, a otras cosas, en lugar de hacerlo de la manera en que se hizo aquí?

Answer 1

Impresionante preparación!

1. Siempre se ve complicado si retrocedes un poco y ves todos los commits antiguos al mismo tiempo. Siempre se estrecha, incluso mirando una historia un poco vieja. Ver http://hg.intevation.org/mercurial/crew/graph/12402?revcount=120 por ejemplo. Esta no es la confirmación más reciente, pero muestra todo el historial hasta esa confirmación.

2. Rebase ayuda mucho, sobre todo si las personas están trabajando en áreas separadas. (Por lo general comprobar el confirmaciones entrantes para ver si hay archivos o funcionalidad posibles conflictos, y si no, yo no rebase.)

Rebase no es a prueba de tontos embargo, por lo Merge es el preferido "seguro" acción, pero deja más "basura" en la historia. Una compensación.

Rebase es algo así como la actualización SVN estándar de la turbera. El material existente se crea como línea de base y tus cambios van por encima, cruza los dedos, sigue funcionando. Es útil, pero a veces te sientes más seguro teniendo el tuyo, el suyo y la fusión como compromisos separados en la historia.

También hay commit-aplastamiento como una opción (extensión histedit tal vez), que aplasta todo en el medio se compromete a uno. Esto es útil cuando está a punto de enviar y desea transferir muchas confirmaciones de parciales en su propio repositorio como una única confirmación a la principal.

Answer 2

tengo 12 desarrolladores que trabajan en el mismo repositorio Mercurial en el trabajo, y nuestra historia se ve nada de eso. Hay confusiones de fusión ocasionales, pero la mayoría de las fusiones provienen de la fusión de sucursales reales, es decir, podría haber una fusión en nuestra rama de desarrollo principal que traiga cambios a partir de una versión de corrección de errores realizada en la rama de producción/publicación.

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

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

Si alguien ha cometido un cambio, Mercurial se queja de que el empuje creará cabezas remotas. El desarrollador hace un hg pull --rebase y vuelve a intentar el empuje. El empuje pasa y todos están felices.

Si está utilizando la integración continua con los desarrolladores de empujar regularmente a un repositorio compartido, este es el camino a seguir. Saber si has promocionado cambios o no es fácil y evitas muchas confusiones de fusión inútiles que llenan tu historial.