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.