Лучшая практика Subversion для слияния ветки с транком, где файловые структуры в ветке были изменены - PullRequest
Новая
       36

Лучшая практика Subversion для слияния ветки с транком, где файловые структуры в ветке были изменены

3 голосов
/ 24 января 2012

Я сталкиваюсь с ситуацией, когда моя команда разработчиков хотела бы реорганизовать файловые структуры в наших репозиториях. Этот процесс займет около 2-3 месяцев. Во время реструктуризации файла нам еще предстоит выпустить программное обеспечение. Итак, после процесса реструктуризации мы хотим объединить организованные файлы из ветви обратно в транк. Важно сохранить историю файлов, а также мы должны иметь возможность объединить изменения кода в стволе с момента первого создания ветви.

Моя первая попытка состояла в том, чтобы создать ветку, а затем просто объединить ее. К сожалению, это не так просто, как я думал. Один из моих тестовых сценариев был следующим:

  1. Создана ветка из ствола
  2. Обновление файла в стволе
  3. Переместить файл в ветку
  4. обновить файл в ветке
  5. Выполнение слияния из ответвления обратно в ствол

На шаге 5 я получил ошибку " tree конфликт " в файле, который я обновляю в транке. TortoiseSVN не предоставляет информацию о том, к какому файлу в ветке относится этот конфликтующий файл. В моем сценарии не так сложно определить файлы с проблемами; однако в нашем реальном хранилище это будет очень сложно, потому что у нас есть тысячи файлов, и многие из этих файлов имеют одинаковые имена файлов (в разных папках).

Есть ли у кого-нибудь опыт в той же ситуации, что и я? Любое предложение / лучшие практики, которые я должен / могу сделать, чтобы обеспечить целостность кодов?

Спасибо за помощь.

Ответы [ 2 ]

2 голосов
/ 25 января 2012

Вот что я в итоге сделал: 1. Объедините все переименованные и измененные файлы в ветке со всеми обновлениями (если применимо) из транка 2. Зафиксируйте ветку в хранилище. Ветвь теперь имеет самый последний код, включая изменения из ствола, так как ветвь была впервые создана 3. Объединить все изменения из ветви обратно в ствол. Транк не будет иметь всей обновленной структуры файлов и всех изменений, которые происходят как в транке, так и в ветви реорганизации

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

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

2 голосов
/ 24 января 2012

Вы можете пойти двумя путями

1. Чисто-SVN метод

После рефакторинга перед объединением /branches/branchname /trunk каталогов , объединение всех переименованных / перемещенных файлов из ветви с их оригиналами магистрали, т.е. /branches/branchname/some/branchfile1 /trunk/trunkfile1 ... и объединить каталоги на последнем шаге

2. Метод DVCS

Используйте любые DVCS с хорошим слиянием (все они имеют it - Git, Mercurial, Bazaar ...) и svn-bridge (git-svn, hgsubversion ...), выполняйте слияние рефакторинга в DVCS-зеркальный репо. В конце концов - линеаризовать репозиторий (история SVN в строке, DVCS-DAG) с помощью инструментов DVCS (... rebase) и отправить результат в SVN-репо. Если перебазировка будет для вас слишком сложной задачей, вы можете экспортировать окончательный результат из DVCS-of-choice (для фона SVN я буду думать о Mercurial или Bazaar, а не Git) в неверсированное дерево и просто сделать WC-однонаправленную синхронизацию магистрали с этим деревом

...