Subversion: обратное слияние?

Question

Я поддерживаю проект, который изначально не использовал систему контроля версий.Вместо этого будут периодические снимки базы кода, сохраняемой в папке резервной копии, и иногда будет создаваться временная ветвь.Когда я заполучил проект, я создал для него хранилище Subversion, зафиксировал каждый снимок в хранилище (используя WinMerge для обновления рабочей копии каждый раз) и создал ветви, соответствующие «дорогим» веткам копии в этой папке резервных копий.system.

Теперь, когда проект некоторое время находился в Subversion, а разработка велась в режиме реального времени в транке, мне дали несколько старых папок моментальных снимков веток, которые были извлечены с компьютера разработчика.,Я нашел правильное место в истории ствола для обратной ветвления ... однако, мой вопрос сейчас таков: если я создаю эту ветку, могу ли я что-нибудь полезное с ней сделать?Могу ли я задним числом объединить эту ветвь с историей ствола, чтобы для файла из ветки была доступна дополнительная история файлов?

По сути, я хотел бы взять эту старую ветвь "дорогой копии", создать ветку из соответствующейместо в истории транка, скопируйте старую ветвь, зафиксируйте каждую старую резервную копию в ветке Subversion, а затем объедините все обратно в соответствующем месте, как это видно на следующей сырой диаграмме ASCII-art:

     trunk: ... r107 -> r108 -\-> r109 -> r110 -> .... -> r137 -> .... -> r394
old branch:                    -> r395 -> r396 -> r397 -/ (r398)

Текущая редакция репозитория - r394.Создание ветки будет r395.Передача пары «дорогих» копий будет r396 и r397.Слияние обратно в транк «до» момента времени, представленного r137, приведет к хранилищу к r398.Теперь просмотр истории файла, начиная с r137 и далее, будет также включать изменения, зафиксированные в r396 + r397 и впоследствии объединенные в r398.

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

Answer 1

Subversion позволяет вам создать ветку из старого снимка, так что вы можете перейти с r108 и зафиксировать свои изменения (r395-397) в этой ветке.Однако вы не можете вернуться и «вставить» коммит в историю дерева.Если у вас есть доступ администратора к серверу, вы можете выполнить какое-то кунг-фу с помощью svnadmin dump, чтобы вставить эти изменения в дерево в соответствующее время в истории, но это приведет к сбросу всех ваших номеров ревизий послеэтот момент (не говоря уже о том, что это будет довольно сложная процедура).Я не могу представить, чтобы этот процесс не вызывал всевозможных неожиданных проблем, особенно с отслеживанием слияний.

Некоторое время назад я пытался сделать нечто подобное и обнаружил, что перенос истории из неорганизованной системы вСистема контроля версий обычно доставляла больше хлопот, чем того стоила.Вместо этого я сделал снимок кода и сделал полный перерыв;все до этого снимка все еще было доступно на старом сервере, используя старую систему, и с этого момента вся разработка будет осуществляться в хранилище Subversion.Мы не потеряли никакой информации, и вся история была там, но разработчикам требовался доступ к старому серверу, чтобы добраться до него.Сначала это раздражало, но через пару месяцев в репозитории Subversion сложилось достаточно истории, что сборки из старой системы, как правило, не использовались и переносились на сервер архивации.Поскольку вы уже настроили репозиторий Subversion и включили исторические сборки, вероятно, уже слишком поздно проводить четкое разделение между унаследованным кодом и текущим кодом, но идея остается в силе.Вы можете добавить эти новые исторические данные на сервер / файловый ресурс, на котором размещены ваши исторические сборки, и если кто-то захочет просмотреть самую подробную историю файла после версии 200 (или любого другого номера оборота, когда вы прекратили фиксировать старые сборки и начали делатьактивная разработка), они могут проверить сервер.