Mercurial Tagging/Branching Strategy

Question

Mi proyecto actual se divide en 3 partes: sitio web, cliente de escritorio y un complemento para un programa de terceros. Comenzamos originalmente con Subversion para nuestro control de fuente pero decidimos probar Mercurial después de leer Joel Spolsky's final post. Teniendo en cuenta que realmente no hemos usado la mayoría del potencial de svn antes, pensamos comenzar de nuevo con algunas ideas básicas de cómo funcionaba el control de fuente que facilitaría esta transición.

Sin embargo, después de configurar nuestro repositorio inicial, estamos perdidos en cuanto a cómo el etiquetado y la ramificación deberían funcionar en un proyecto como este.

Básicamente, estamos trabajando en las 3 partes al mismo tiempo. Queremos que un lanzamiento sea una combinación de las 3 partes. Actualmente estamos trabajando en un repositorio.

Para la parte del complemento, tenemos la primera iteración finalizada a la que nos hemos referido como Plug-In v0.1. Para la primera versión oficial de las otras dos partes, también nos gustaría referirnos a ellas como Website v0.1 y Desktop Client v0.1. Cuando las tres partes estén en v0.1, nos gustaría tener un proyecto completo v0.1.

Nuestro problema es que no estamos seguros de cómo gestionar todo esto en el repositorio de Hg. ¿La mejor manera de manejar esto sería crear 3 repositorios separados para las 3 versiones estables y luego 3 repositorios más para los desarrollos actuales? Actualmente tenemos este repositorio todo en uno. ¿Deberíamos hacer esto en las sucursales (son ramas diferentes de los repositorios de clonación?) Y las etiquetas?

Cualquier ayuda es muy apreciada.

Answer 1

Definitivamente parece que desea repositorios separados para las 3 partes, si necesita vincular los 3 juntos en las versiones, también puede ser útil tener estos 3 repositorios como subrepos de un repositorio general de proyectos.

Answer 2

Intente utilizar Joel's Tutorial on Mercurial. Esto podría rendir un poco más o cómo usarlo. Realmente no hay una "ramificación" como se usa en SVN y realmente, podría ser una buena idea dejar de tratar de usar Mercurial como si fuera SVN. En lugar de Branching, tienes tus propios repositorios locales.

Answer 3

Recomiendo encarecidamente la entrada de blog de Steve Losh A Guide to Branching in Mercurial, donde describe varios enfoques de bifurcación compatibles con Mercurial.

El uso de la función de ramas con nombre de Mercurial es probablemente la coincidencia más cercana a la bifurcación con SVN.

Answer 4

Puede guardarlos en un repositorio o separar los proyectos. Para mí, esto dependerá de qué parte del código, si lo hay, se comparte entre las aplicaciones. Si el código no se comparte entre los componentes, use un repositorio diferente para cada uno.

Los repositorios separados le permiten etiquetar fácilmente cada componente con la versión (v0.1) y luego continuar con el desarrollo según sea necesario. Cuando esté listo para lanzar un producto combinado, simplemente extraiga la etiqueta deseada para cada repositorio y obtendrá la versión completa del producto. Si tiene entregas para la aplicación que no están relacionadas con ninguno de los tres componentes, también puede crear un repositorio para el producto combinado para mantener esa información. Puede gestionar la bifurcación de cada uno de los componentes a través de sucursales o repositorios clonados.

Si mantiene los componentes en un único repositorio, seguirá funcionando, pero las etiquetas y las ramas se volverán mucho más complicadas. Cuando el complemento llegue a v0.1, cree una etiqueta para eso como "plug-in v0.1". Haga lo mismo para los clientes de escritorio y web. Luego, cuando desee lanzar el producto, tendrá que extraer de tres etiquetas diferentes que tienen cada componente en v0.1.

Yo optaría por los repositorios por separado. La decisión es más complicada si hay un código compartido, pero podría encontrar formas de tomar sus dependencias como bibliotecas en lugar de código.

Para sus preguntas sobre la bifurcación, this article es una buena guía para las diferentes opciones y ventajas y desventajas.