Cómo gestionar el desarrollo concurrente con mercurio?

Question

Esta es una mejor pregunta práctica, y espero que la respuesta sea "depende". Sólo espero aprender más escenarios del mundo real y los flujos de trabajo.

En primer lugar, estoy hablando de diferentes cambios para el mismo proyecto, por lo que no subrepo favor.

digamos Vamos que tiene su base de código en un repositorio de Hg. Se empieza a trabajar en una nueva función complicada A, entonces un error complicado B es informado por su probador de confianza (que tiene probadores, ¿verdad?).

Es trivial si (la solución para) B depende de R. simlply ci A continuación, ci B.

Mi pregunta es qué hacer cuando son independientes (o al menos eso parece ahora).

Me puede pensar en las siguientes maneras:

1. Usar un clon independiente para B.
2. Uso ramas anónimas o con nombre, o marcadores, en el mismo repositorio.
3. Uso MQ (con el parche B en la parte superior de A).
4. Uso ramificado MQ (explicaré más adelante).
5. Uso MQ múltiple (desde 1,6)

1 y 2 están cubiertos por una excelente el blog por @Steve de Losh enlazadas desde una pregunta un poco relacionado .

El enorme ventaja de 1 sobre las otras opciones es que no requiere ningún reconstruir cuando se cambia de trabajo en una cosa a la otra, ya que los archivos están físicamente separados e independientes. Por lo que es realmente la única opción si, por ejemplo, A y / o B toca un archivo de cabecera que define un valor lógico de los tres estados y se incluye por miles de archivos de C (no me diga que no han visto ese código legado base).

3 es probablemente el más fácil (en términos de configuración y gastos generales), y se puede voltear el orden de A y B, si B es una solución pequeña y / o urgente. Sin embargo, puede ser complicado si A y B toca el mismo archivo (s). Es fácil trozos de parche solución que no pudieron aplicarse si los cambios A y B son ortogonales dentro del mismo archivo (s), pero conceptualmente es todavía un poco arriesgado.

4 puede causar mareos, pero es la forma más potente y flexible y escalable. Yo descuido hg qinit con -c ya que quiero parches marca el trabajo en progreso y push / pull ellos, pero sí tener un salto conceptual para darse cuenta de que se puede ramificar en MQ repo también. Estos son los pasos (mq = hg --mq):

1. hg qnew bugA; hacer cambios para A; hg qref
2. mq branch branchA; hg qci
3. hg qpop; mq up -rtip^
4. hg qnew bugB; hacer cambios para B; hg qref
5. mq branch branchB; hg qci
6. para trabajar en un nuevo: hg qpop; mq up branchA; hg qpush

Parece una locura tomar tantas medidas, y siempre que lo necesite el trabajo interruptor debe hg qci; hg qpop; mq up <branch>; hg qpush. Pero considere esto: usted tiene varias ramas de liberación nombradas en el mismo repositorio, y hay que trabajar en varios proyectos y correcciones de errores, al mismo tiempo para todos ellos (que es mejor que recibir un bono para este tipo de trabajo garantizado). Se podría perderse muy pronto con los otros enfoques.

Ahora mis amantes hg compañeros, ¿hay otras alternativas mejores /?

---

(UPDATE) qqueue casi hace # 4 obsoleto. elegante descripción de ver a Steve de Losh aquí .

Answer 1

Parece que no hay opciones más o mejores que los que se enumeran en la pregunta. Así que aquí están de nuevo.

1. Usar un clon por proyecto.
   • Pros:. Separación total, por lo tanto no reconstruir cuando se cambia de proyectos
   • Contras:. Necesidades de las herramientas principales para cambiar entre dos clones
2. Uso anónima o ramas nombradas, o marcadores, en el mismo repositorio.
   • Pros: hg estándar (o cualquier DVCS) la práctica; limpia y clara.
   • Contras:. Debe comprometerse antes de cambiar y reconstruir después
3. Uso MQ con un parche (o múltiples parches consecutivos) por proyecto.
   • Pros:. Simple y fácil
   • Contras: mosto qrefresh antes de la conmutación y reconstruir después; complicado y arriesgado si los proyectos no son ortogonales.
4. Usar una rama MQ (o qqueue en 1.6+) por proyecto.
   • Pros: de ultra flexible y escalable (para el número de proyectos concurrentes)
   • Contras: qrefresh mosto y qcommit antes de la conmutación y reconstruir después; se siente complicado.

Como siempre, no hay bala de plata, por lo que escoger y elegir el más adecuado para el trabajo.

---

(UPDATE) Para cualquier persona que está enamorada de MQ, MQ utilizando en la parte superior de las ramas regulares (# 2 + # 3) es probablemente la más común y la práctica preferible.

Si tiene dos proyectos concurrentes con la línea de base en dos ramas (por ejemplo al lado de liberación y la versión actual), es trivial para saltar entre ellos de esta manera:

hg qnew; {coding}; hg qrefresh; {repeat}
hg qfinish -a
hg update -r <branch/bookmark/rev>
hg qimport -r <rev>; {repeat}

En el último paso, qimport debe añadir una opción de -a para importar una línea de conjuntos de cambios a la vez. Espero Meister Geisler da cuenta de esto:)

Answer 2

Siempre usaría ramas nombradas, ya que permite a Mercurial hacer su trabajo: para mantener su historial de proyectos, y recordar por qué hizo lo que cambia en orden a su código fuente. Si tener un clon o dos sentado en su disco es generalmente una tarea fácil, dada mi estilo de trabajo, al menos:

1. ¿Su proyecto carecen de un proceso de construcción, de modo que usted puede probar y ejecutar las cosas bien desde el código fuente? Entonces voy a tener la tentación de tener un solo clon, y de vuelta hg up adelante y hacia atrás cuando tengo que trabajar en otra rama.

2. Pero si usted tiene un buildout, virtualenv, u otra estructura que consigue construida, y que divergen fuerzas entre las dos ramas, a continuación, hacer un hg up luego esperar a que el proceso de generación de repetición puede ser un gran dolor , sobre todo si las cosas como la creación de una base de datos de la muestra son los involucrados. En ese caso, sin duda usar dos clones, uno que se sienta en la punta del tronco, y que está sentado en la punta de la rama de la característica de emergencia.

Answer 3

Así que la pregunta es, en el momento en que le dicen a dejar de trabajar en función de A, B y empezar rasgo independiente, ¿qué opciones alternativas están ahí, para:? Cómo gestionar el desarrollo concurrente con mercurial

Echemos un vistazo en el problema de concurrencia retira, la misma forma en que escribe roscado código- definir un flujo de trabajo sencillo para resolver cualquier problema que le ha asignado, y aplicarlo a cada problema. Mercurial se unirá a la obra, una vez que se hace. Así, programador Un trabajará en función de programador A. B trabajará en función B. Ambos acaba de pasar a ser usted. (Si sólo tuviéramos cerebros de varios núcleos:)

Siempre usaría ramas nombradas, ya que permite a Mercurial hacer su trabajo: para mantener su historial de proyectos, y recordar por qué hizo lo que cambia en orden a su código fuente.

Estoy de acuerdo con el sentimiento de Brandon, pero me pregunto si se pasa por alto que la función A no ha sido probado? En el peor de los casos, las compilaciones de código y pasa las pruebas unitarias, pero algunos métodos implementan los requisitos anteriores, y algunos métodos implementan los nuevos. Un diff contra el anterior registro de entrada es la herramienta que utilizaría que me ayude a volver a la pista con la característica a.

Es el código para la función de A en un punto en el que normalmente se echa en? El cambio de función de A a trabajar en función de B no es una razón para cometer código a la cabeza o a una rama . Sólo comprobar en el código que compila y pasa sus pruebas. Mi razón es que, si las necesidades del programador C para comenzar característica C, un nuevo máximo de pago de esta rama ya no es el mejor lugar para empezar. Mantenimiento de la cabeza rama sana, significa que puede responder rápidamente, con más fiable correcciones de errores.

El objetivo es tener su código (probado y verificado) en funcionamiento, por lo que desea todo el código que terminan combinó en la cabeza (de sus ramas de desarrollo y de legado). Mi punto parece ser, he visto ramificación utilizado de manera ineficiente: código se vuelve rancio y luego no se utiliza, la fusión se hace más difícil que el problema original.

Sólo la opción 1 tiene sentido para mí. En general:

1. Usted debe pensar en sus obras de código, antes de que alguien lo ve.
2. Favor de la cabeza sobre una rama.
3. Rama y el registro de entrada si alguien está recogiendo el problema.
4. Rama si el sistema automatizado o probadores necesitan su código solamente.
5. Rama si son parte de un equipo, trabajando en un problema. Consideramos que es la cabeza, consulte 1-4.

Con la excepción de los archivos de configuración, los procesos de construcción debe ser una caja y un solo comando de construcción. No debería ser más difícil de cambiar entre los clones, que para un nuevo programador para unirse al proyecto. (Admito mi proyecto necesita un poco de trabajo aquí.)