¿Cómo gestiona los cambios menores que desea mantener locales en mercurial?

Estoy considerando migrar un repositorio de cvs de 14 años (historial intacto) a mercurial. Creo que tengo todos los bits de conversión técnica, pero todavía tengo algunas preguntas sobre cómo trabajar eficazmente en mercurial.

Una de las cosas que veo mucho en los sandboxes de cvs de los desarrolladores individuales (incluido el mío) son los cambios locales no confirmados que no están listos para ser llevados a la línea principal. Tengo entendido que esto es algo malo. La mayoría de mis experimentos con hg sugieren que los cambios no comprometidos son algo malo. La incapacidad de fusionarse con ellos es suficiente para eso. Entonces, lo que quiero saber es cómo otras personas que usan mercurial en la codificación diaria lo manejan. ¿Cómo maneja los cambios incompletos en el código cuando llega el momento de actualizar su repositorio? ¿Cómo manejas los cambios locales que (todavía) no quieres compartir con otros desarrolladores?

Lo manejo de esta manera:

En mi repositorio local, confirmo cada cambio, incluso si estoy experimentando. Si estoy de acuerdo con el experimento, y está probado, lo envío al repositorio remoto. Si no, permanece en mi repositorio local (o vuelve a una revisión anterior).

La idea es que el repositorio remoto solo contenga versiones funcionales y probadas de mis proyectos.

Hay un par de cosas que agregaré.

Una es sugerir un flujo de trabajo que haga un uso juicioso de la estantería , que se envía de manera estándar con TortoiseHg .

Cada vez que quería comprometer parte de mi directorio de trabajo actual, archivaba los cambios que no quería confirmar, volvía a compilar (para asegurarme de que no había archivado bits que ahora resultan en una compilación rota) y luego ejecutaba mis pruebas . Luego, me comprometería con el conjunto completo, funcional y probado. Finalmente correría sin ayuda para restaurar mis cambios.

Si tuviera cambios bastante más permanentes, digamos que quería que un archivo de configuración en mi máquina de desarrollo apuntara siempre al puerto 3333 localhost en lugar del servidor de producción, entonces buscaría usar la extensión Mercurial Queues, que se envía con Mercurial y TortoiseHg .

No creo que los cambios no comprometidos sean intrínsecamente algo malo. Se refiere a una "incapacidad para fusionarse con ellos": si tiene un cambio no confirmado en algún archivo, y extrae y actualiza un cambio en ese archivo, Mercurial comenzará el proceso de fusión como si lo hubiera comprometido, luego solicitó una fusión ¿Querías decir algo diferente?

Entonces, para los cambios locales que aún no desea compartir con otros desarrolladores, tiene dos enfoques. El primero es mantener los cambios en su copia de trabajo, pero no empujarlos, y el otro es dejarlos de lado, fuera de la copia de trabajo. El que elija depende de si desea tener estos cambios disponibles mientras trabaja.

Si los mantiene en la copia de trabajo, los cambios entrantes funcionarán bien, por lo que solo debe evitar crear cambios salientes, y eso significa evitar comprometerlos. Si los archivos son nuevos, eso es fácil, simplemente no lo haga hg add. Si ya están rastreados, puede excluirlos específicamente de las confirmaciones con hg commit --exclude foo.txt. Si tiene una gran cantidad de archivos para excluir, o los excluirá de muchas confirmaciones (por ejemplo, para un cambio permanente en un archivo de configuración local), mire la extensión de exclusión .

Si está preparado para mover los cambios a un lado, tiene otro conjunto de opciones. Lo más simple es simplemente usar hg diffen los archivos para producir un parche que los describa, que guarde en un lugar seguro, y luego hg patch --no-commitvolver a aplicar ese parche cuando desee que los cambios vuelvan. Puede suavizar esto instalando la extensión de estantería , la extensión del ático o algún otro pariente. También podría usar la extensión de colas , pero eso es usar un mazo para romper una nuez. Incluso podría simplemente confirmar los cambios, luego actualizar de nuevo al padre y realizar otro trabajo allí, dejando los cambios en una rama anónima rechoncha hg commit -m 'temporary branch' && hg up $(hg log -r 'parents(.)' --template '{node}')(¡aunque puede ser más fácil hacerlo manualmente!). Sin embargo, debería tener cuidado de no impulsar ese conjunto de cambios.

Se utilizan dos enfoques básicos para separar las corrientes de desarrollo.

• Ramas nombradas. La idea es que trabajes en tu propia rama, nmichaels_branch_of_awesome. De esa manera, puede confirmar sus cambios sin freír el trabajo de otras personas. Luego, se fusiona con otras personas cuando necesita su trabajo, y cuando llega el momento de la función, pasa a la rama más estable para la integración. Estoy a favor de las ramas con nombre.

• Clon anónimo. Esto crea un repositorio separado para su sandbox. Aquí juegas hasta que obtienes lo que quieres, luego (probablemente) haces un parche MQ para tus commits y avanzas hacia donde comenzaste. No me gusta mucho este enfoque, ya que requiere la administración de directorios y, potencialmente, el trabajo de MQ, lo que puede ser complicado. Y con algunos repositorios, pueden comenzar a crecer un poco para esto. Dicho esto, esto parece ser preferido por los desarrolladores de Kiln.