Можно ли «злоупотреблять» функцией переименования Mercurial для отслеживания перемещения блоков кода?

Question

Иногда я обнаруживаю, что у меня есть файл, который со временем вырос и содержит больше классов / функций / того, что мне нравится.Время рефакторинга!В этом случае я обычно нахожу, что один мой файл становится несколькими: сам по себе плюс несколько других файлов, каждый из которых содержит отдельные сегменты файла.

К сожалению, просто создание этих новых файлов немного «ломает» историю - это сложносказать, что эти функции изначально пришли из другого файла.Еще хуже, если бы были какие-либо другие изменения, внесенные в код во время рефакторинга.

Один из моих коллег обнаружил, что он может "злоупотребить" функциональностью переименования, сделав что-то вроде этого:

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

В результате каждый новый файл выглядит как переименование, а остальная часть файла удалена, а исходный файл выглядит так, как будто он потерял удаленные блоки.Пока что это кажется идеальным.Тем не менее, я обеспокоен тем, что эти множественные переименования вызовут некоторые путаницы в будущем.

Что-то не так с этим подходом "множественных переименований"?

Answer 1

Вы должны убедиться, что знаете, что на самом деле означает hg copy , прежде чем делать это.

Короче говоря, при копировании файла из original_file в new_file_1 добавляется ссылка, что Mercurialбудет использовать в будущих слияниях тогда и только тогда, когда не сможет найти new_file_1 в общем предке.Обычно это будет иметь место только в первом слиянии после создания копии.

График может проиллюстрировать это лучше:

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

Мы начнем с набора изменений, где у вас есть файл old.Затем вы редактируете old в одной ветви и копируете old в new в другой.В первом слиянии редактирование в old копируется в new.Во втором слиянии нет специальной обработки для new, поскольку у общего предка (copy old new changeset) найдено new.

Что это означает для вашего случая, это то, что существует большая разница вбудущее сливается в зависимости от того, когда люди увидят copy old new.Если вы можете заставить всех использовать

old --- copy old new

в качестве отправной точки, тогда все в порядке.Но если кто-то имеет ответвления от набора изменений old и фактически отредактировал old в этой ветви, тогда они получат конфликты слияния при попытке слияния с набором изменений copy old new.

Точнее,они получают конфликты слияния, если они редактировали какую-либо часть файла old, которая не была скопирована в файл new.Конфликты слияния предупреждают вас о том, что в old произошло изменение, которое необходимо скопировать в new.Однако, когда вы действительно сделали

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

, вы получите несущественные конфликты слияния в двух из трех новых файлов.

Если вы только что удалили файл old и добавили триновые файлы, тогда вы все равно получите здесь конфликт слияния: вас спросят

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

Предпочитаете ли вы видеть это приглашение или видите, что запуск инструмента слияния - ваше дело, но теперь вы знаете,последствия hg copy (или hg rename --after, это действительно одно и то же).

Answer 2

Проще использовать hg copy для этого:

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

Теперь все 3 имеют оригинальную историю.Но, да, в любом случае это совершенно нормально и обычно делается.