mercurial - name - tag in bitbucket
Usar Mercurial para separar la versión privada y pública (3)
(una vez que se empuja la historia, ¡no hay marcha atrás!)
Seguro que hay ... ¡de eso se trata el control de versiones!
No he hecho algo así antes, pero parece que el comando de trasplante será útil. Además, puedes tener clones de clones e impulsarlos a cualquiera de ellos, etcétera.
¿Cómo usaría Mercurial para el siguiente problema?
Supongamos que tengo una biblioteca Core. Ahora quiero desarrollar una extensión a esa biblioteca llamada Extensión. Deseo mantener Core separado físicamente de la extensión, es decir, digamos que Core es una biblioteca de código abierto y Extension es una biblioteca privada que se basa en Core (tal vez contenga algunas cosas que quiero mantener como personal. Lo que sea). Obviamente, no quiero llevar toda la fuente en Extensión al repositorio público. Pero, por otro lado, es posible que desee impulsar ciertos cambios de la extensión al núcleo (si decidiera "donar" parte de la extensión al núcleo) o viceversa (si quiero incorporar correcciones de errores, por ejemplo).
¿Cómo haría esto para minimizar el riesgo de perder Extension to Core (una vez que se envía el historial al servidor público, no hay marcha atrás), mientras se mantiene flexible para hacer esto para ciertos cambios. Sucursales? Clones? Mqs? ¿Algo más?
Actualmente solo estoy familiarizado con los repositorios de clonación, y muy parecido a su simplicidad.
EDITAR: se me ocurrió este esquema, pero no puedo lograr que funcione en Windows. Dos repositorios (Core y Extensión). En Extension hay dos ramas , también Core y extensión. Ahora, puedes registrar un enlace en el repositorio de Mercurial, así que me gustaría registrar un enlace ''pretxnchangegroup'' en el Repo Core que no permite los checkins desde la rama Extension, como se explica en el libro de Mercurial . Excepto que no logro que funcione en Windows. Asi que:
- Alguien tiene un ejemplo de algo como esto (de hecho, cualquier gancho que cambia el resultado de una transacción) en Windows?
- Todavía podría usar el trasplante para marcar los cambios de la extensión a la rama Core, ¿verdad?
La extensión Forest le permite guardar varios repos como parte de uno grande. Parece que eso podría ayudar aquí.
Después de algunas pruebas, voy a probar este esquema. Dos repositorios principales y dos ramas nombradas, Core y Extension.
Un repositorio Core principal, que solo debe contener los conjuntos de cambios Core y la fuente. Por lo tanto, debería contener solo conjuntos de cambios de la rama Core. Esto se comprueba utilizando el siguiente enlace de repositorio en hgrc de ese repositorio:
pretxnchangegroup.branch = hg heads --template "current branches: {branches} " | find "Extension" && exit 1 || exit 0
Parece un poco extraño, pero básicamente se dispara después de que se completa un empujón o un tirón, pero antes de que se haya cometido. En ese punto, si el gancho falla, la transacción se retrotrae. Por lo tanto, el gancho busca un conjunto de cambios de la rama Extensión y falla si lo encuentra, lo que impide efectivamente que los cambios de Extensión ingresen al Repo Core.
El segundo repositorio contiene ramas y conjuntos de cambios principales y de extensión, y es donde se intercambian los conjuntos de cambios entre las dos ramas. Combinación normal de Core a Extension y trasplante de Extension a Core.
Espero que esto ayude a alguien más.