Восстановление ручного слияния с SVN-слиянием

Question

Я пытаюсь исправить проект SVN, в котором произошло следующее:

Ветвь функции была взята из транка. В эту ветку регулярно совершались коммиты.Когда пришло время слить ветку обратно в транк, разработчик использовал не SVN-слияние, а WinMerge (!), Поэтому мы потеряли всю нашу историю для этого.Кроме того, было исправлено несколько небольших ошибок, которые были пропущены в руководстве WinMerge.Это произошло несколько недель назад, и с тех пор были регулярные коммиты на транк, поэтому мы не можем просто вернуться.

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

Если я попытаюсь вернуться к точке, предшествующей этому "BadMerge", а затем выполнить правильное слияние, я не смогу повторно объединить другие произошедшие измененияпосле BM.

Итак, я думаю, что должен использовать svnadmin dump и load, аналогично this , но я не могу точно определить, что мне нужно делать.

1. Дамп изменений до BM (ChangesetX).
2. Дамп изменений после BM (ChangesetY.
3. Загрузка ChangesetX в какой? Новый репо?
4. Делать правильноСлияние этого
5. Load ChangesetY

Возможно ли это? Любая помощь будет принята с благодарностью.

Спасибо

Том

Answer 1

Что вы можете сделать, это:

1. Бросьте SVN книгу этому разработчику, предпочтительно в виде распечатки на каком-то тяжелом виде бумаги. (Если ему удастся пережить это, уволить его.)

2. Существует возможность для SVN проходить режимы слияния и запись , ревизии которых были объединены в свойствах файла и папки, но фактически не изменять какие-либо файлы . (Использование болтовни SVN: их «статус свойства» «изменен», а «текстовый статус» - нет.)

Некоторое время я не использовал командную строку SVN, поэтому не знаю, как это сделать, но TortoiseSVN имеет следующее:

Answer 2

Вероятно, не самый элегантный способ, но выполнимый на стороне клиента:

• svn export HEAD транка в каталог A
• svn извлечение BAD_COMMIT транка в каталог B
• копирование файлов из A в B

B теперь содержит все коммиты после BAD_COMMIT как локальные изменения (вы теряете различие между этими коммитами).

Now:

• svn извлечение BAD_COMMIT-1 транка в каталог C
• выполнить svn слияние вашей ветви и отправную точку вашей ветки транка в рабочую копию C
• скопироватьC to A

Теперь у вас есть правильное слияние в каталоге A при локальных изменениях в HEAD.Фиксация A. В магистрали теперь есть правильное слияние как HEAD.

Наконец:

• svn обновление B до HEAD
• разрешение конфликтов
• принятие B

В этот момент вы совершили вменяемое слияние и все изменения после неудачного слияния.Вы теряете некоторую историю, но у вас меньше хлопот, чем при работе с дампами на стороне сервера.

Удачи!

Answer 3

Вы не ограничены тем, что принимаете то, что ваш инструмент управления версиями считает общей основой , и запись слияния, подобная sbi , предполагает, что , вероятно, хорошая идея.Если все остальное терпит неудачу, вы всегда можете выполнить слияние вручную, проверив три версии файла и использовать KDiff3 непосредственно для тех, которые описаны в ответе, связанном выше.

Если версии Xи Y относятся к ветви функций, а версии от A до E находятся в транке,

    A----------+
    |          |
    |          |
   \_/        \_/
    B          X
    |          |
    |          |
   \_/        \_/
    C <======= Y   Merge without being recorded by svn as a merge (right?), aka BadMerge
    |
    |
   \_/
    D
    |
    |
   \_/
    E

Затем, чтобы повторить слияние, проверьте версии A, Y и B и объедините с kdiff3.Это даст вам новую версию C ', в которой предпочтительно не будет ошибок, представленных в C.Затем вы хотите, чтобы остальные изменения были выполнены в транке, поэтому объедините C', C и E.Это должно дать вам новую версию, которую вы можете зарегистрировать как версию F.

Я не знаю svn достаточно хорошо, чтобы дать какой-либо совет о том, как вы должны зарегистрироваться в C' и как с этим справиться, ноописанные выше действия должны как минимум дать желаемый конечный результат.