Flujo de trabajo mercurial para ~ 15 desarrolladores - ¿Deberíamos usar ramas con nombre?

Question

Mi equipo acaba de comenzar con Mercurial y un repositorio central. Tenemos a Hudson construyendo la punta de la rama "predeterminada", que es básicamente nuestra línea principal. Teníamos una política de check-in con nuestro VCS antiguo que las revisiones de códigos, pruebas, etc. deben hacerse antes de registrarse en la línea principal.

Por lo tanto, digamos que usted está trabajando en la característica X. Se trabaja en algunas cosas, basándola off de "default", y luego se comete un rasgo parcial como un puesto de control. Localmente, su "valor predeterminado" ahora está roto; todavía no lo ha compartido con nadie, pero si hiciera un esfuerzo, ahora tiene un código roto en la línea principal.

Incluso si espera para presionar hasta que lo haya solucionado todo, parece que hay situaciones (por ejemplo, trabajar en dos cosas a la vez) en las que tendría que realizar algunos cambios, pero no todos.

Además, si te registras en todos los cambios de punto de control, entonces habrá algunas revisiones en línea principal que se acumulan, y otros en la línea principal de que no construyen.

Hemos empezado a utilizar ramas nombradas - pero el más lectura que hago cuanto más pienso que estamos mal uso de ramas nombradas.

¿Alguna sugerencia sobre cómo configurar un buen flujo de trabajo que nos permite ejecutar Hudson y mantener nuestra política de línea principal?

Answer 1

Puede considerar al menos dos repositorios. El repositorio "mainline" tiene su código probado y revisado. El código solo se envía a este repositorio después de que Hudson lo haya probado y después de las revisiones que haya realizado. El repositorio de "prueba" sería un clon de la línea principal. Este es el repositorio que Hudson monitorea, por lo que cada vez que se envía un conjunto de cambios al repositorio de pruebas, Hudson lo prueba. Probablemente pueda configurar un paso de compilación Hudson que impulse los cambios desde el repositorio de pruebas a su línea principal si las pruebas pasan.

Desarrolladores siempre empujan al repositorio de pruebas, pero sólo tirar desde la línea principal, por lo que sólo alguna vez tiran en el código de prueba. Si necesitan compartir conjuntos de cambios no probados, podrían empujar/jalar directamente entre los repositorios locales de los demás. Quizás es posible configurar Hg para que la línea principal solo acepte impulsos del repositorio de pruebas, de modo que los desarrolladores no puedan presionar accidentalmente a la línea principal en lugar de probar.

Podría ser bueno tener un repositorio de revisión también. Así que los desarrolladores presionan para que se realicen las pruebas, Hudson empuja el código probado para revisarlo, y luego el código revisado se envía a la línea principal.

Descargo de responsabilidad: Solo he usado Hg en proyectos triviales y de manera trivial.

Answer 2

Lo que hacemos en mi empresa es utilizar la rama denominada para distinguir la versión estable (en la que solo corregimos errores) y la siguiente versión en la que ocurre el desarrollo y respaldamos correcciones de estable a predeterminado de forma regular (con hg merge stable en la rama predeterminada).

Para la revisión del código utilizamos la extensión mq para permitir a los desarrolladores enviar parches limpios. Y los desarrolladores pueden extraer de los depósitos de los demás, sin contaminar el repositorio de referencia.

Descargo de responsabilidad: no usamos Hudson.

Answer 3

Es una cuestión de mentalidad. Los VCS distribuidos no requieren que mantenga un único depósito central.

En lugar de tener la línea principal abierta para que todos la puedan registrar, configúrela con acceso de escritura limitado.Solo los conjuntos de cambios que han sido aprobados (probados, firmados, lo que sea lógico para usted) se incorporan a la línea principal.

La manera de administrar los cambios en la línea principal es una pregunta abierta con muchas respuestas posibles. Aquí hay dos cosas fuera de mi cabeza:

• Los desarrolladores pueden acceder libremente a un repositorio central de "pruebas", desde el cual se revisan los cambios.
• Haga que los desarrolladores publiquen changesets en sus propias estaciones de trabajo (recuerde, las sucursales son baratas) y haga que el proceso de revisión principal los recoja directamente desde allí.

Answer 4

En primer lugar, recomiendo altamente A Guide to Branching in Mercurial

A continuación, se puede empujar simplemente la rama actual: Nudge - A Gentler Version of Push

Y tal vez podría decidir permitir sólo una cabeza por sucursal: 32. Prevent a push that would create multiple heads

Otros SO preguntas relacionadas con las sucursales con nombre:

• Mercurial: Named Branches vs Multiple Repositories
• Mercurial repository layout for multiple branches

Answer 5

También podría considerar el uso de la extensión Bookmarks en lugar de ramas nombradas.

Si está familiarizado con git, los marcadores se comportan como git-branches en lugar de mercurial branches.