Revisiones mercuriales y de código; buen flujo de trabajo?

Question

Estoy en un pequeño equipo distribuido usando Mercurial para un repositorio central. Cada uno lo clonamos a través de ssh en nuestros propios linux boxes. Nuestra intención es revisar el trabajo de los demás antes de llevar los cambios al repositorio central, para ayudar a mantener limpia la punta del centro. ¿Cuál es una buena forma de compartir código entre desarrolladores en diferentes linux boxes? Soy nuevo en Mercurial. Las opciones que puedo pensar (a través de la lectura, no la experiencia) son:

1: Autor confirma todos los cambios locales y las actualizaciones de clonación de trabajo con la sugerencia de la central. El autor utiliza el paquete hg, si hay una forma de especificar qué ingresos locales incluir en el paquete. (Un experimento me mostró que "paquete" solo capta cambios sin compromiso, incluso si hay confirmaciones locales previas que la central no sabe). El autor obtiene el archivo del paquete para el revisor. El revisor crea una nueva clonación limpia de la punta central e importa el paquete en esa clonación. o,

2: Después de que el autor y el revisor obtengan de la punta central, el autor usa el parche y el revisor importa el parche. o,

3: El autor empuja al revisor o al revisor a extraer del autor (pero ¿cómo exactamente? Lo que leo solo trata de empujar y tirar desde/hacia el repositorio servido original, y/o en el mismo cuadro en lugar de entre diferentes cuadros de Linux.)

4: Olvídese de revisar el código antes de presionar a central; siga adelante y presione, usando etiquetas para identificar lo que se ha revisado o no, y use Hudson (que ya funciona) para etiquetar la última compilación segura para que los miembros del equipo puedan saber de cuál sacarla.

Si su equipo utiliza Mercurial y revisa los códigos, ¿cómo hace para que el revisor vea sus cambios?

Answer 1

La mayoría de estos son posibles, algunos son más tediosos que otros.

1. Puede usar paquete especificando la punta de la repo central como el --base:
   hg bundle --base 4a3b2c1d review.bundle
2. ser que también acaba usar paquete. De esta forma, los datos del conjunto de cambios también están incluidos.
3. Puede empujar (y tirar) hacia (desde) cualquier repositorio que tenga un antecesor (es) común (es). Si quiere sacar de uno de sus colegas, solo necesita ejecutar hg serve en su máquina, y podrá tirar.
4. Esto también funciona, pero deberá mantener varias cabezas y tener cuidado con la fusión. Si no lo hace, puede ser fácil basar un cambio estable en un conjunto de cambios no revisados, lo que hará que sea difícil deshacerlo si necesita corregir ese conjunto de cambios sin revisar más adelante.

De las opciones que presentó, # 1 y # 3 son probablemente las más fáciles, dependiendo de si puede alcanzar las cajas de las otras.

En una nota relacionada: Esta es la pregunta que hizo que mi colega y yo empezáramos a desarrollar Kiln, nuestra herramienta de alojamiento y revisión de código (Fog Creek) Mercurial. Nuestro plan y el prototipo inicial mantendrían múltiples repositorios, un repositorio "central" y un conjunto de repositorios de "revisión". El proceso de revisión se iniciará al clonar el repositorio central en un repositorio de revisión en el servidor, y luego ejecutar una diferencia de repositorio completo entre los dos, con una interfaz web simple para obtener y visualizar los diffs.

Hemos evolucionado bastante ese flujo de trabajo, pero la idea general, tener un repositorio de rama para enviar cambios no revisados ​​y una interfaz para revisarlos antes de insertarlos en el repositorio central, sigue siendo el mismo. No quiero anunciar aquí, pero sí recomiendo giving it a try.

Answer 2

La mitad de la respuesta a esta pregunta está usando ReviewBoard con Mercurial extention. Permite a empujar ciertas revisiones para revisión emitiendo el siguiente comando

hg tip postreview

Answer 3

Voy a añadir una quinta opción - hago todo el trabajo de desarrollo en las ramas con nombre, de preferencia uno por tarea. Permitir que cualquier cosa se confíe a una rama con nombre de "desarrollo", ya sea que esté en estado de trabajo o no.

Empuje hacia el repositorio central, haga que el revisor tire de la rama. Realice la revisión en la rama.

Cuando la revisión haya pasado, combine el trabajo de desarrollo en la rama de características adecuada.

Este flujo de trabajo, que es (para mí) sorprendentemente impopular, tiene muchas ventajas:

1. Todo el trabajo se ha comprometido - usted no tiene que esperar para una revisión por hacer antes de comprometerse.

2. No creará la versión incorrecta. Solo crea desde la rama de características.

3. El trabajo en curso no interfiere con otros desarrolladores.

4. Desde la rama de desarrollo, puede ver los últimos cambios (por ejemplo, los conjuntos de cambios que abordan comentarios de revisión), compararlos con el punto de ramificación o compararlos con la última rama de características, que pueden proporcionar información útil.