Как объединить два файла в системе контроля версий

Question

Я делаю рефакторинг моего C ++ проекта, содержащего много исходных файлов. Текущий этап рефакторинга включает в себя объединение двух файлов (скажем, x.cpp и y.cpp) в больший (скажем, xy.cpp) с выбрасыванием некоторого кода и добавлением еще некоторого кода.

Я хотел бы сообщить своей системе управления версиями (в моем случае, Perforce), что полученный файл основан на двух предыдущих файлах, поэтому в будущем, когда я посмотрю историю изменений xy.cpp, я также увижу все изменения, когда-либо сделанные в x.cpp и y.cpp.

Perforce поддерживает переименование файлов, поэтому, если бы y.cpp не существовало, я бы точно знал, что делать. Perforce также поддерживает слияние, поэтому, если бы у меня было 2 разные версии xy.cpp, он мог бы создать одну версию из него. Из этого я выясняю, что возможно объединение двух разных файлов (не уверен насчет этого); Тем не менее, я просмотрел некоторую документацию по Perforce и другим системам контроля версий и не нашел ничего полезного.

Возможно ли вообще то, что я пытаюсь сделать?
У него есть обычное имя (поиск в документации по «объединению» или «объединению» был неудачным)?

Answer 1

Вы можете попробовать интегрировать с необоснованными слияниями (-i в командной строке).Если я правильно понимаю документацию (и я никогда не использовал ее сам), это приведет к интеграции двух файлов.Затем вам нужно будет разрешить интеграцию по вашему выбору, что приведет к чему-то близкому к предполагаемому файлу.

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

Answer 2

Легкая часть была бы такой:

p4 edit x.cpp y.cpp
p4 move x.cpp xy.cpp
p4 move y.cpp xy.cpp

Тогда сложная часть решает задачу перемещения y.cpp и выполняет ваш рефакторинг. Но это скажет Perforce, что файлы объединены.

Answer 3

Я не думаю, что это можно сделать в классическом VCS.
Эти системы управления версиями бывают двух видов (слайд 50+ из Getting git by Scott Chacon ):

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

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