Usando Mercurial para separar versiones privadas y públicas.

Question

¿Cómo utilizarías Mercurial para el siguiente problema?

Supongamos que tengo un núcleo de biblioteca. Ahora quiero desarrollar una extensión para esa biblioteca llamada Extensión. Quiero mantener Core separado físicamente de Extension, es decir, decir 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 personal. Lo que sea). Obviamente, no quiero enviar toda la fuente en Extensión al repositorio público nunca. Pero, por otro lado, podría querer impulsar ciertos cambios de Extensión a Núcleo (si yo decidiera "donar" parte de la Extensión al Núcleo) o viceversa (si quiero incorporar correcciones de errores, por ejemplo).

¿Cómo abordaría esto, minimizando el riesgo de fugas de Extensión a Núcleo (una vez que el historial se envía al servidor público, no hay vuelta atrás), mientras se mantiene flexible para hacer esto para ciertos cambios? ¿Ramas? Clones? Mqs? ¿Algo más?

Actualmente, solo estoy familiarizado con los repositorios de clonación, y me gusta mucho su simplicidad.

EDITAR: Se me ocurrió este esquema, pero no logro que funcione bajo Windows. Dos repositorios (Core y Extension). En Extensión hay dos sucursales , también Core y extensión. Ahora, puede registrar un gancho por repositorio en Mercurial, así que me gustaría registrar un gancho 'pretxnchangegroup' en el repositorio Core que no permite registros en la rama de Extensión, tal como se explica en en el libro Mercurial . Excepto que no consigo que funcione bajo las ventanas. Entonces:

• ¿Alguien tiene un ejemplo de algo como esto (de hecho, cualquier gancho que cambie el resultado de una transacción) bajo windows?
• Todavía podría utilizar el trasplante para realizar cambios en los cambios de la extensión a la rama principal, ¿no?

Answer 1

Después de algunas pruebas, voy a probar este esquema. Dos repositorios principales y dos ramas con nombre, Core y Extension.

Un repositorio Core principal, que solo debe contener los conjuntos de cambios Core y la fuente. Por lo tanto, debe contener solo conjuntos de cambios de la rama Core. Esto se verifica mediante el siguiente enlace del repositorio en hgrc de ese repositorio:

pretxnchangegroup.branch = hg heads --template " sucursales actuales: {sucursales} " | encuentra " Extensión " & amp; & amp; salida 1 || salir 0

Parece un poco raro, pero básicamente se dispara después de que se completa un empuje o tirón, pero antes de que se cometa. En ese momento, si el enlace falla, la transacción se retrotrae. Así que el gancho busca un conjunto de cambios de la rama de la Extensión y falla si lo encuentra, lo que prohíbe efectivamente que los cambios de la Extensión ingresen en el repositorio del Core.

El segundo repositorio contiene conjuntos y conjuntos de cambios Core y Extension, y es donde los conjuntos de cambios se intercambian entre los dos. La fusión normal de Core a Extension y el trasplante de Extension a Core.

espero que esto ayude a alguien más.

Answer 2

  

(una vez que se empuja el historial, hay   no volveremos!)

seguro que hay ... ¡de eso se trata el control de versiones!

No he hecho nada como esto antes, pero parece que El comando de trasplante será útil. Además, puedes tener clones de clones y enviarlos a cualquiera de ellos, etcétera.

Answer 3

La Extensión del bosque le permite mantener varios repositorios como parte de uno grande Suena como que podría ayudar aquí.