control de versiones: moviendo una corrección de errores/mejora del código en el desarrollo de características

Tengo una pregunta relacionada con el flujo de trabajo de Mercurial (posiblemente aplicable a otros DVCS).control de versiones: moviendo una corrección de errores/mejora del código en el desarrollo de características

El repositorio se configura con la configuración típica predeterminada/estable.

Se le ha encomendado la tarea de crear una nueva función y esperar que tarde algún tiempo (mes +). Mientras trabajas en esta característica, te encuentras con un error que crees que debería arreglarse y aplicarse a la producción más temprano que tarde. O quizás, nota algún código que podría documentarse mejor.

Mi suposición es que usted hace la corrección por defecto y luego cambia a estable y realiza la corrección de nuevo (a mano o aplicando un parche). ¿Es correcto o debería cambiar de inmediato a estable, hacer el cambio allí y luego fusionar estable en predeterminado?

El uso de un parche parece tener más sentido para mí. Puede hacer una confirmación específica para la corrección de errores y aplicar ese parche a su conveniencia. Quiero decir, si el error no es muy desagradable, no hay necesidad de urgencia y romper su flujo. ¿Derecha?

Entonces, ¿cómo manejas esta situación?

Gracias

Fuente

2011-01-13 jbarreiros

Nota: Wim propone una alternativa viable a la selección de cerezas que podría considerar. – VonC

Puede volver al punto de ramificación (revisión B), reparar el fallo no (revisión X) y luego fusionar el arreglo en ambas ramas (M1 y M2):

-----B--o----o---M1----o---> stable 
    |  /
    |---------X bugfix 
    |   \ 
    \--o---o----M2----o-----> feature

esta manera se puede obtener su solución en cada rama con operaciones normales hg merge; no se requieren parches, trasplantes ni MQ.

Llevando la misma idea un paso más allá: en cambio, podría volver a la revisión que introdujo el error en primer lugar. Al usar esto como base para la corrección, se asegurará de que pueda fusionar su solución en cualquier rama que contenga el error.

Fuente

2011-01-13 20:05:06

Huzzah, para el tipo que entiende "dónde" haces el cambio es tan importante como el cambio en sí mismo. –

+1 para evitar la reescritura de historial. – VonC

Entiendo por qué uno no quiere duplicar el historial, pero para las soluciones simples, "trasplantar" parece ser el método más fácil, que también parece mantener la línea de tiempo agradable y lineal, donde una fusión puede complicar un poco la línea de tiempo. ¿Estoy siendo perezoso? – jbarreiros

Una vez que haya hecho su pequeño arreglo comprometen, se puede utilizar el Hg Transplant Extension e informar de esa misma corrección en otra rama.

Si esto no es apropiado, se detallan otras posibilidades de recolección de cerezas en la pregunta "Mercurial cherry picking changes for commit".

Fuente

2011-01-13 17:45:08 VonC

Gracias VonC, la extensión de trasplante funcionará muy bien. Gracias por el enlace también. – jbarreiros

Se puede evitar esto con un mejor flujo de trabajo. La solución de Wim a continuación es preferible porque no termina con el mismo cambio dos veces en su repositorio con diferentes hash-id. Hacer el mismo cambio en dos lugares hace que la fusión eventual de esos lugares sea menos automática. –

@ Ry4an: estoy de acuerdo. Una vez más, razono demasiado como un usuario de Git;) – VonC

control de versiones: moviendo una corrección de errores/mejora del código en el desarrollo de características

Respuesta

Cuestiones relacionadas