¿Cómo puedo evitar que algunas modificaciones se propaguen en mercurial?

mercurial-queue

Question

Estoy desarrollando una base de datos web que ya está en uso para una docena de instalaciones separadas, la mayoría de las cuales también administro. Cada instalación tiene bastante configuración y personalización local. Después de haber cambiado a mercurial desde svn, me gustaría aprovechar su naturaleza distribuida para realizar un seguimiento de las modificaciones locales. He configurado cada servidor instalado como su propio repositorio (y configuré apache para que no sirva a los directorios .hg).

Mi dificultad es que el árbol de desarrollo también contiene configuración local, y quiero evitar colocar cada bit en un archivo de configuración no versionada. Entonces, ¿cómo configuro las cosas para evitar la propagación de la configuración local al repositorio maestro y a las copias instaladas?

Ejemplo: Tengo un archivo largo config.ini que debe ser versionado y distribuido. La versión "limpia" contiene marcadores de posición para los parámetros de conexión de la base de datos, y no quiero que las contraseñas del servidor de desarrollo terminen en los repositorios para las copias instaladas. Pero de vez en cuando haré cambios (por ejemplo, nuevos valores predeterminados) que necesito propagar. Hay varios archivos en una situación similar.

Lo mejor que pude hacer hasta ahora es instalar mq y convertir las modificaciones locales en un parche (dos parches, en realidad, con conjuntos de cambios lógicamente separados). Cada vez que deseo enviar un conjunto de cambios regular al repositorio local , necesito abrir todos los parches, confirmar las modificaciones y volver a aplicar los parches. Cuando esté listo para avanzar al repositorio maestro, debo volver a abrir los parches, presionarlos y volver a aplicarlos. Todo esto es intrincado y propenso a errores.

La única alternativa que puedo ver es olvidarme del empuje y solo propagar los conjuntos de cambios como parches, lo que parece una solución aún peor. ¿Alguien puede sugerir una mejor configuración? No me puedo imaginar que esta sea una configuración tan inusual, pero no he encontrado nada al respecto.

Editar: después de seguir las sugerencias aquí, estoy llegando a la conclusión de que las ramas nombradas más rebase proporcionan una solución simple y viable. He agregado una descripción en forma de mi propia respuesta. Por favor echa un vistazo.

Answer 1

1 Mercurial tiene (seguimiento de los comentarios) confirmación selectiva (basada en cadenas) - ver la extensión de registro

2 Los cambios locales dentro de los archivos públicos versionados se pueden recibir fácilmente con MQ Extension (lo hago para las configuraciones de sitio todo el tiempo) . Tu dolor de cabeza con MQ

Cada vez que deseo enviar un conjunto de cambios regular al repositorio local, necesito abrir todos los parches, confirmar las modificaciones y volver a aplicar los parches. Cuando esté listo para avanzar al repositorio maestro, debo volver a abrir los parches, presionarlos y volver a aplicarlos.

es el resultado de un flujo de trabajo no depurado y (algunas) malas interpretaciones. Si quiere comprometerse sin MQ-patches, no lo haga a mano. Agregue alias para commit, que qop -all + commit y use este nuevo comando solamente. Y cuando presione, puede que no se preocupe por el estado MQ: empuja los conjuntos de cambios desde el repositorio, no desde el estado WC . El repositorio local también se puede proteger sin alias mediante el contenido de comprobación de gancho precompromiso.

3 Puede probar la extensión LocalBranches, donde los cambios locales se almacenan dentro de las sucursales locales (y fusionar las ramas en los cambios). Esto me pareció más problemático en comparación con MQ.

Answer 2

Según sus comentarios, parece que ya está familiarizado con las mejores prácticas para tratar con esto: versione una plantilla de configuración y mantenga la configuración real sin versión.

Pero como no está contento con esa solución, aquí hay otra que puede probar:

Mercurial 2.1 introdujo el concepto de Fases . La fase es metadatos del conjunto de cambios que lo marcan como "secreto", "borrador" o "público". Normalmente, mercurial y sus extensiones utilizan y manipulan estos metadatos de forma automática, sin que el usuario deba tenerlos en cuenta.

Sin embargo, si creó un conjunto de cambios 1234 que no desea enviar a otros repositorios, puede aplicar esto marcándolo manualmente como secreto de esta manera:

hg phase --force --secret -r 1234

Si luego intenta ingresar a otro repositorio, se ignorará con esta advertencia:

pushing to http://example.com/some/other/repository
searching for changes
no changes found (ignored 1 secret changesets)

Esta solución te permite

1. versión los cambios de configuración local
2. evitar que esos cambios sean empujados accidentalmente
3. fusiona tus cambios locales con otros cambios que hagas

La gran desventaja es, por supuesto, que no puede impulsar los cambios que realizó sobre este conjunto de cambios secretos (porque eso empujaría el conjunto de cambios secretos). Deberá volver a establecer los cambios antes de poder aplicarlos.

Answer 3

Si el problema con una plantilla versionada y una copia local no versionada es que los cambios en la plantilla no se convierten en copias locales, ¿qué le parece modificar su aplicación para usar un localconfig.ini no versionado y una alternativa a la localconfig.ini por falta? parámetros. De esta forma, se pueden agregar nuevos parámetros predeterminados a config.ini y propagarse a su aplicación.

Answer 4

Habiendo seguido las sugerencias aquí, llegué a la conclusión de que las sucursales nombradas más rebase proporcionan una solución simple y confiable. He estado usando el siguiente método desde hace un tiempo y funciona muy bien. Básicamente, el historial en torno a los cambios locales se divide en ramas con nombre que se pueden reorganizar fácilmente con rebase.

Utilizo una rama local para obtener información de configuración. Cuando todos mis repos admitan Fases, marcaré el secret sucursal local; pero el método funciona sin eso. local depende del default , pero el valor predeterminado no depende de lo local por lo que puede enviarse de forma independiente (con hg push -r default ). Así es como funciona:

1. Supongamos que la línea principal de desarrollo está en la rama default . (Podrías tener más ramas, esto es por concreción). Hay un repositorio maestro (estable) que no contiene contraseñas, etc.

   ---o--o--o (default)

2. En cada clon desplegado (sin desarrollo), creo una sucursal local y le asigno todo el estado local.

   ...o--o--o (default)
   /
   L--L (local)

3. Las actualizaciones de upstream siempre estarán en default. Cada vez que retiro actualizaciones, las combino en local ( n es una secuencia de nuevas actualizaciones):

   ...o--o--o--n--n (default)
   / /
   L--L--N (local)

   La sucursal local realiza un seguimiento de la evolución del default , y aún puedo regresar a las configuraciones anteriores si algo sale mal.

4. En el servidor de desarrollo, comienzo con la misma configuración: una rama local con configuración de configuración como la anterior. Esto nunca será empujado. Pero en la punta de lo local creo una tercera rama, dev . Aquí es donde ocurre un nuevo desarrollo.

   ...o--o (default)
   /
   L--L (local)
   /
   d--d--d (dev)

5. Cuando estoy listo para publicar algunas características en el repositorio principal, primero rebase toda la rama de desarrollo al default :

   hg rebase --source "min(branch(''dev''))" --dest default --detach

   El árbol anterior se convierte en:

   ...o--o--d--d--d (default)
   /
   L--L (local)

   Los conjuntos de cambios reubicados ahora pertenecen a la rama default . (Con ramas de características, agregue --keepbranches al comando rebase para retener el nombre de la rama). Las nuevas características ya no tienen antepasados ​​en local , y puedo publicarlos con push -r default sin arrastrar a lo largo de las revisiones locales. (Nunca fusione de local a default , solo al revés). Si se olvida de decir " -r default al presionar, no hay problema: su empuje es rechazado ya que agregaría un nuevo cabezal.

6. En el servidor de desarrollo, fusiono las revoluciones reajustadas en local como si acabara de sacarlas:

   ...o--o--d--d--d (default)
   / /
   L--L-----N (local)

7. Ahora puedo crear una nueva rama de desarrollo además de local , y continuar el desarrollo.

Esto tiene los beneficios que puedo desarrollar en una configuración configurada y controlada por la versión; que no necesito meterme con parches; que las etapas de configuración anteriores permanecen en el historial (si mi servidor web deja de funcionar después de una actualización, puedo actualizar a una versión configurada ); y que solo rebase una vez, cuando estoy listo para publicar cambios. La rebase y la fusión posterior pueden generar conflictos si una revisión entra en conflicto con los cambios de configuración locales; pero si eso va a suceder, es mejor si ocurren cuando las instalaciones de fusión pueden ayudar a resolverlos.