Uso de Mercurial para separar la versión privada y pública

Question

¿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. Quiero 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 deseo 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 fugas 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 estoy familiarizado con los repositorios de clonación, y me gusta su simplicidad.

EDIT: Se me ocurrió este esquema, pero no puedo lograr que funcione en Windows. Dos repositorios (Core y Extensión). En Extensión hay dos ramas , también Core y extensión. Ahora, puede registrar un gancho en Mercurial en el repositorio, así que me gustaría registrar un enlace 'pretxnchangegroup' en el Repo Core que no permita los checkins desde la rama Extension, como se explicó en in the Mercurial book. Excepto que no logro que funcione en Windows. Entonces:

• Alguien tiene un ejemplo de algo como esto (de hecho, cualquier gancho que cambia el resultado de una transacción) en Windows?
• Aún podré usar el trasplante para hacer cambios rápidos desde la extensión hasta la rama Core, ¿verdad?

Answer 1

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 mediante el gancho siguiente repositorio en hgrc de ese repo:

pretxnchangegroup.branch = hg heads --template "current branches: {branches} " | find "Extension" && exit 1 || exit 0

se ve un poco raro, pero básicamente es despedido después de un empuje y de tracción se ha completado, pero antes de que se ha comprometido. 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 principales y de extensión y conjuntos de cambios, y es donde se intercambian 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.

Answer 2

(una vez que se empuja la historia, hay hay vuelta atrás!)

de que hay ... eso es lo que el control de versiones se trata!

No he hecho algo así antes, pero parece que el comando transplant será útil. Además, puedes tener clones de clones e impulsarlos a cualquiera de ellos, etcétera.

Answer 3

El Forest extension le permite mantener varios repos como parte de uno grande. Parece que eso podría ayudar aquí.