2009-07-24 7 views
7

Es la primera vez que uso un DVCS y también como desarrollador solitario, la primera vez que uso ramas, así que tal vez me falta algo aquí.Almacenar ramas con nombre por separado en mercurial sin tener que fusionarlas

Tengo un repositorio remoto desde el cual extraje los archivos y comencé a trabajar. Los cambios se enviaron al repositorio remoto y, por supuesto, este simple escenario funciona bien.

Ahora que mi aplicación web tiene algunas características estables, me gustaría empezar su despliegue y por eso clonado el repositorio remoto a un directorio nuevas ramas/estable fuera de mi directorio de trabajo para la rama por defecto y se utiliza:

hg branch stable 

para crear una nueva rama con nombre. Creé un conjunto de scripts de implementación que solo necesita la rama estable y los comprometí según las necesidades. De nuevo, esto funcionó bien.

Ahora, cuando volví a mi directorio de trabajo inicial para trabajar en algunas características nuevas, descubrí que Mercurial insiste en que SOLO UNA cabeza esté en el repositorio remoto. En otras palabras, tendría que fusionar las dos ramas (por defecto y estable), agregando las secuencias de comandos de implementación innecesarias a mi rama predeterminada para avanzar al repositorio principal. Esto podría empeorar si tuviera que hacer un cambio en un archivo en mi rama estable para poder implementarlo.

¿Cómo puedo mantener mis ramas con nombre separadas en Mercurial? ¿Tengo que crear dos repositorios remotos separados para hacerlo? En cuyo caso, las sucursales nombradas pierden su valor. ¿Me estoy perdiendo de algo?

Respuesta

3

Después de leer el section on named branchy development en el libro de Mercurial, he llegado a la conclusión de que, personalmente, la mejor práctica es tener repositorios compartidos separados, uno para cada rama. Estaba en la cuenta gratuita en bitbucket.org, por lo que intentaba obligarme a usar solo un repositorio compartido, lo que creó el problema.

He mordido la viñeta y he conseguido una cuenta paga para poder mantener un repositorio compartido por separado para mis lanzamientos estables.

+2

¿Qué te hizo concluir eso? No veo nada allí que diga "Las ramas nombradas son malas". Personalmente creo que es mucho más fácil trabajar con ellos que con varios repositorios. –

+3

"En la mayoría de los casos, aislar sucursales en repositorios es el enfoque correcto. Su simplicidad facilita su comprensión, por lo que es difícil cometer errores. Existe una relación uno a uno entre las sucursales en las que está trabajando y directorios en su sistema. Esto le permite usar herramientas normales (no compatibles con Mercurial) para trabajar en archivos dentro de una sucursal/repositorio ". - Del libro Mercurial Personalmente, para mí, la sugerencia dada anteriormente conduce a un modelo mental más simple. También modifiqué mi respuesta. –

+1

Ah, supongo que no estoy de acuerdo con que eso simplifique las cosas. ¿Qué pasa si su código necesita estar en una ubicación específica en su sistema de archivos? ¿Copias/cambias el nombre de las carpetas cada vez que quieres cambiar de sucursales? Si alguien quiere obtener todas las sucursales en un proyecto, ¿deberían realmente tener que clonar todo el proyecto varias veces? –

2

Usted escribió:

descubrí que Mercurial insiste en solamente un cabezal de estar en el repositorio remoto.

¿Por qué crees que es así?

De la ayuda de hg push:

Por defecto, empuje se negará a ejecutar si se detecta el resultado sería aumentar el número de cabezas remotas. Esto generalmente indica el que el cliente olvidó tirar y fusionar antes de presionar.

Si sabe que está creando intencionadamente un nuevo encabezado en el repositorio remoto, y esto es deseable, use el distintivo -f.

+0

¿Es esta la práctica aceptada? ¿Está bien tener múltiples cabezas en el repositorio remoto? –

+0

He visto un par de publicaciones en blogs que mencionan que es una mala práctica tener varias cabezas en un repositorio compartido y esto tiene sentido. –

+0

+1, gracias por apuntarme en la dirección correcta. –

11

Utilice hg push -f para forzar la creación de un nuevo cabezal remoto.

La razón push no lo hará de forma predeterminada es que está tratando de recordarle que tire y se fusione en caso de que lo haya olvidado.Lo que haces no quiere que suceda es:

  • Usted y yo echa un vistazo a la revisión 100 de la rama "X" llamado.
  • Usted se compromete localmente y empuja.
  • Me comprometo localmente y presiono.

Ahora rama X es la siguiente con el repositorio remoto:

--(100)--(101) 
    \ 
     \---------(102) 

Qué cabeza debe agarrar un nuevo desarrollador si se va a retirar la rama? Quién sabe.

+0

Creo que el desarrollador debe clonar todo el repositorio y actualizar a la rama X. Luego terminaría en la revisión 102 (la revisión más importante de X). El desarrollador puede simplemente fusionar las dos cabezas si sabe cómo, o puede dejar eso a otra persona. –

1

Vengo de git esperando lo mismo. Simplemente presionando la parte superior parece que podría ser un enfoque.

Hg empuje -r punta

Cuestiones relacionadas