Flujo de trabajo de la Junta de revisión para el repositorio de Mercurial

Question

En mi empresa estamos tratando de agregar prácticas de revisión de código en nuestro proceso de desarrollo y para ello decidimos usar Review Board.

Mientras Review Board debe funcionar de la caja para Subversion, el flujo de trabajo para Mercurial parece un poco complicado. En primer lugar, parece que solo se admite la revisión de publicaciones (mediante el script posterior a la revisión) para este tipo de reportes. En segundo lugar, no está clara la documentación de si la revisión posterior en realidad es compatible con Mercurial (solo menciona git).

¿Podrían ustedes describir su flujo de trabajo en detalle, por favor?

Estoy en lo cierto en mi pensamiento que debe ser algo como esto:

Desarrollador:

1. repo maestro clon
2. clon característica de recompra de recompra maestro local
3. truco-hack en función Repo
4. commit en repo de característica
5. de alguna manera ejecutar post-revisión de la función repo contra par ent repo maestro

Crítico:

1. opinión diff
2. si bien a continuación, tire al repositorio principal de la cesión temporal característica

Answer 1

Acabamos de empezar a utilizar tanto Mercurial como ReviewBoard en mi empresa. Hacemos algo similar al flujo de trabajo sugerido, excepto que normalmente no nos molestamos con los repositorios de características, y siempre presionamos al máster en lugar de extraerlo del máster. El problema principal con el uso de ReviewBoard con DVCS es cuando desea que alguien revise un cambio de, por ejemplo, revisión 2 a revisión 3, ambos en su repositorio local pero no en el maestro al que ReviewBoard tiene acceso. a, por ejemplo, porque todavía está esperando una revisión de los cambios de la revisión 1 a la revisión 2.

solución de Reviewboard a esto es lo que llama "padre" diffs; esto significa que en vez de subir el patch que desea revisado, también se tiene que cargar el diff entre la versión más reciente en el repositorio principal y la revisión de los padres de su parche. Esto permite que ReviewBoard reconstruya los archivos de origen para el lado izquierdo de su visor de diff lado a lado.

La versión actual de ReviewBoard no admite diferencias parentales para Mercurial, pero he enviado un parche para que funcionen; Creo que esto debería ser para RC3.

También he parcheado la extensión ReviewBoard mencionada en la publicación anterior para permitir que admita diferencias padre. Los pondré a disposición una vez que se publique RC3.

Answer 2

Hay una extensión de mercurio por lo que quieres hacer:

http://blogma.de/projects/mercurial-reviewboard.html
https://www.mercurial-scm.org/wiki/ReviewboardExtension

El flujo de trabajo que presenta parece fácil de seguir, así que creo que está en el camino correcto. La forma en que los servicios de DVCS (es decir bitbucket o github) manejan esto es en realidad la misma:

commiter:
los pasos 1 ... 4 el mismo
5. Enviar una solicitud de extracción al mantenedor (esto es eran su revisión de código encaja)

revisor:
1. revisiones de la solicitud de extracción
2. tira

Desde este enfoque funciona perfectamente para los servicios antes mencionados, no creo que se debería presentar ningún problema.

Answer 3

Ahora hay un nombre de extensión FileReview que está integrado con TortoiseHg (a partir de TortoiseHg> = 0.9). Las revisiones parecen estar integradas en el repositorio.

No logró que funcione en Windows, pero espero que se mejore.

Answer 4

No conozco el tamaño de su equipo, pero las revisiones de publicaciones se vuelven rápidamente inmanejables, especialmente en equipos grandes, proyectos de seguridad crítica y cuando los revisores están ocupados.

GitHub y Bitbucket resolver este problema con un enfoque que no era viable en la era pre-DVCS, utilizando la llamada tirón solicita.

Concepto en pocas palabras: el desarrollador se compromete con su propio clon y luego solicita al propietario del repositorio principal que lo lleve al repositorio principal. El propietario lo revisa y puede aceptar o rechazar tirar de él al maestro. Es así de simple. Es posible que desee ver el video Git Workflows Demo: What is the Integrator Workflow? en YouTube. Esto se aplica a Mercurial, también.