Gestionando sucursales de lanzamiento en mercurial.

Question

Recientemente cambié de SVN a Mercurial. Ahora me pregunto cómo realizar el flujo de trabajo de bifurcación previsto en Mercurial de acuerdo con las buenas prácticas, con la esperanza de que otros desarrolladores entiendan lo que sucede en el repositorio.

Este es el flujo de trabajo:

1. Por lo general, tengo una rama troncal / predeterminada donde se realiza el trabajo en la serie de publicación actual. Digamos que es 1.x. Al mismo tiempo, uso una rama 2.x para trabajar en la próxima versión principal. Los cambios en esta rama pueden ser radicales, por lo que la fusión con la rama troncal / por defecto / 1.x no tiene sentido aquí.
   • Después de un tiempo, el trabajo en 2.x puede finalizar y la versión 2.0 se lanzará. Ahora quiero que la rama 2.x sea la nueva rama predeterminada / troncal y que la rama predeterminada / troncal actual sea la rama 1.x.
   • Repitiendo este proceso, puede venir una nueva rama 3.x. Como antes, si se lanza 3.0, 3.x debería convertirse en la nueva rama predeterminada, mientras que la actual por defecto debería convertirse en la rama 2.x (otra vez).

Mi pregunta es no si este flujo de trabajo es bueno (supongo que no es fundamentalmente incorrecto). Mi pregunta es si la forma en que me doy cuenta de esto en Mercurial puede considerarse una buena práctica o si hay mejores oportunidades.

Así es como planeo administrar las sucursales en Mercurial ...

Comenzando desde un repositorio con una sola rama que contiene el código de la versión actual de la serie 1.x:

$ hg init
$ echo "hello world" > file1.txt
$ hg ci -A -m "Initial commit of 1.x code"

Comienza a trabajar en la versión 2.x:

$ hg branch 2.x
$ hg ci -m "Create new branch for 2.x development"
$ echo "Big new feature for 2.x" > file2.txt
$ hg ci -A -m "Add big new feature"

Mientras tanto, realice algunos trabajos en la serie de lanzamiento actual (1.x):

$ hg up default
$ echo "Minor adjustments specific for 1.x" > file3.txt
$ hg ci -A -m "Minor adjustments"

Después de algún tiempo, la versión 2.0 está lista, yippee! Haz que la rama predeterminada a 1.x y 2.x a predeterminada :

$ hg up default
$ hg branch 1.x
$ hg ci -m "Make default branch to 1.x branch"
$ hg up 2.x
$ hg ci --close-branch -m "Close branch 2.x"
$ hg branch --force default
$ hg ci -m "Make former 2.x branch to new default"

Ahora cree una nueva rama 3.x y trabaje en ella, también trabaje en predeterminado . Nuevamente, después de algún tiempo, 3.0 está listo y es hora de administrar los nombres de las sucursales:

$ hg up default
$ hg branch --force 2.x # (reuse previously closed 2.x branch name)
$ hg ci -m "Make default branch to 2.x branch"
$ hg up 3.x
$ hg ci --close-branch -m "Close branch 3.x"
$ hg branch --force default
$ hg ci -m "Make former 3.x branch to new default"

El repositorio ahora puede tener este aspecto ('o' son las cabezas):

o Branch default (3.x)
|
| o Branch 2.x
 \|
  | o Branch 1.x
   \|
    |
    .

El punto principal sobre el que no estoy seguro es si reutilizar los nombres de rama y hacer malabares con el nombre de rama predeterminado es una buena práctica.

Mucho texto para esa pregunta, lo siento, pero quería dejar claro lo que estoy haciendo.

Answer 1

Esto es lo que haría:

Haz que default sea tu " mainline " rama. La punta de esta rama es la " actualmente lanzada al público " Versión de tu código. Las correcciones de errores críticos pueden comprometerse directamente con esta rama y fusionarse en ramas de desarrollo.

Para comenzar a trabajar en la versión 2.0, cree una rama 2.0-dev . Confirma los cambios para 2.0 en esa rama y combina correcciones de errores críticos de la línea principal ( predeterminado ) en ella. Una vez que hayas terminado con 2.0, combina 2.0-dev en predeterminado y etiqueta el resultado como 2.0 .

Hacer las cosas de esta manera significa que no tiene que preocuparse por hacer malabarismos con los nombres de las ramas, y puede combinar las correcciones de errores críticos de la línea principal en las ramas de desarrollo con bastante facilidad.

También se adapta bien cuando está trabajando en varias versiones futuras a la vez (por ejemplo, 2.1 y 3.0). Periódicamente puede combinar los cambios 2.1 en 3.0 para mantener la versión 3.0 actualizada.

Terminarás con un gráfico como este:

$ hg glog -l 1000
@       changeset:  25:efc0096f47c0  tip
|       summary:    Added tag 3.0 for changeset d1a7fc3d7d77
|
o       changeset:  24:d1a7fc3d7d77  3.0
|\      summary:    Merge in the redesign changes.
| |
| o     changeset:  23:b5b69d24c8f7 3.0-dev
| |     summary:    Finish 3.0 redesign.
| |
| o     changeset:  22:4c2f98fac54b 3.0-dev
|/|     summary:    Merge in the latest changes to 2.1/mainline.
| |
o |     changeset:  21:37df04521032
| |     summary:    Added tag 2.1 for changeset 39ecc520fc0a
| |
o |     changeset:  20:39ecc520fc0a  2.1
|\ \    summary:    2.1 development is done.
| | |
| o |   changeset:  19:208f3f9236af 2.1-dev
| | |   summary:    Finish the 2.1 work.
| | |
| | o   changeset:  18:4a024009a9d6 3.0-dev
| | |   summary:    More redesign work.
| | |
| | o   changeset:  17:00c416888c25 3.0-dev
| |/|   summary:    Merge in changes from the 2.1 branch to keep the redesign current.
| | |
| o |   changeset:  16:a57e781a0db1 2.1-dev
| | |   summary:    More 2.1 work.
| | |
| | o   changeset:  15:ddeb65402a61 3.0-dev
| | |   summary:    More redesign work.
| | |
+---o   changeset:  14:90f5d7a8af9a 3.0-dev
| | |   summary:    Merge in the fire fixes.
| | |
| o |   changeset:  13:78a949b67bb9 2.1-dev
|/| |   summary:    Merge in the fire fixes.
| | |
o | |   changeset:  12:6dfe9d856202
| | |   summary:    Oh no everything is on fire, fix it in the mainline.
| | |
| o |   changeset:  11:86767671dcdb 2.1-dev
| | |   summary:    Smaller changes for 2.1.
| | |
| | o   changeset:  10:25dec81d2546 3.0-dev
| | |   summary:    Work more on the redesign.
| | |
+---o   changeset:  9:42c7d689fb24 3.0-dev
| |     summary:    Start working on a complete redesign.
| |
| o     changeset:  8:3da99186ca7d 2.1-dev
|/      summary:    Start working on 2.1.
|
o       changeset:  7:9ba79361827d
|       summary:    Added tag 2.0 for changeset 755ed5c5e291
|
o       changeset:  6:755ed5c5e291  2.0
|\      summary:    Merge in the dev branch for 2.0.
| |
| o     changeset:  5:44a833fcc838 2.0-dev
| |     summary:    Finish work on 2.0.
| |
| o     changeset:  4:d7ba6aae1651 2.0-dev
|/|     summary:    Merge in the critical fix.
| |
o |     changeset:  3:968049f1b33a
| |     summary:    Fix a critical bug on the main branch.
| |
| o     changeset:  2:917869609b25 2.0-dev
| |     summary:    More work on the new version.
| |
| o     changeset:  1:f95798b9cb2e 2.0-dev
|/      summary:    Start working on version 2.0.
|
o       changeset:  0:8a3fb044d3f4
        summary:    Initial commit.

Answer 2

Creo que deberías considerar esto: un modelo de bifurcación de git exitoso .

No soy un gran fan de git, pero este modelo es muy útil para mercurial también.