¿Está bien "abusar" de la funcionalidad de cambio de nombre de Mercurial para seguir el movimiento de los bloques de código?

A veces me parece que tengo un file que con el time ha crecido para contener más classs / funciones / elementos que me gustan. ¡Es hora de refactorizar! Generalmente encuentro en este caso que mi único file se convierte en varios: en sí mismo más varios otros files, cada uno con distintos segmentos del file.

Desafortunadamente, la simple creación de estos nuevos files "rompe" la historia un poco; es difícil decir que esas funciones originalmente provenían de otro file. Es aún peor si se hicieron otros cambios en el código durante la refactorización.

Uno de mis compañeros de trabajo descubrió que podía "abusar" de la funcionalidad de cambio de nombre haciendo algo como esto:

hg rename --after original_file new_file_1 hg rename --after original_file new_file_2 hg rename --after original_file new_file_3 hg add original_file 

El resultado es que cada uno de los files nuevos se ve como un cambio de nombre con el rest del file eliminado, y el file original parece que perdió los bloques eliminados. Hasta ahora, esto parece ideal. Sin embargo, me preocupa que estos múltiples cambios de nombre vayan a causar confusas fusiones más adelante.

¿Hay algo de malo en este enfoque de "cambiar el nombre de varias veces"?

Debes asegurarte de que sabes lo que realmente significa hg copy antes de hacer esto.

En resumen, copyr un file de original_file a new_file_1 agrega un enlace que Mercurial usará en futuras fusiones si y solo si no puede encontrar new_file_1 en el antecesor común. Normalmente, este solo será el caso en la primera fusión después de hacer la copy.

Un gráfico podría ilustrar esto mejor:

 old --- edit old --- edit in old copied to new --- edit old --- merge \ / / copy old new --/------- edit new ------------/ 

Comenzamos con un set de cambios donde tienes el file old . Luego edita old en una twig y copy de old a new en otra. En la primera fusión, la edición old se copy en new . En la segunda fusión no hay un tratamiento especial para los new ya que se encuentra new en el ancestro común (el copy old new set de cambios copy old new ).

Lo que esto significa para su caso es que hay una gran diferencia en las fusiones futuras dependiendo de cuándo la gente ve la copy old new . Si puedes hacer que todos lo usen

 old --- copy old new 

como punto de partida, entonces las cosas están bien. Pero si alguien tiene twigs fuera del old set de cambios y realmente editado old en esa twig, entonces obtendrán conflictos de combinación cuando intenten fusionarse con el copy old new set de cambios.

Más precisamente, obtienen conflictos de combinación si han editado alguna parte del file anterior que no se haya copydo en el new file. Los conflictos de fusión lo alertan sobre el hecho de que hubo un cambio en la old que debe copyrse en uno new . Sin embargo, cuando realmente lo hiciste

 hg copy old new1 hg copy old new2 hg copy old new3 

entonces obtendrá conflictos de fusión irrelevantes en dos de los tres files nuevos.

Si acabaras de eliminar el file anterior y agregaras tres files nuevos, entonces seguirías teniendo un conflicto de fusión aquí: se te preguntará

 remove changed old which local deleted use (c)hanged version or leave (d)eleted? 

Ya sea que prefiera ver ese aviso o ver el inicio de la herramienta de fusión depende de usted, pero ahora usted sabe las consecuencias de hg copy (o hg rename --after después de que realmente es lo mismo.

Más fácil es usar la hg copy para eso:

 hg copy original_file new_file_1 hg copy original_file new_file_2 hg copy original_file new_file_3 

Ahora los 3 tienen la historia original. Pero, sí, de cualquier manera esto está perfectamente bien y se hace comúnmente.

    Intereting Posts