Svn: заменить багажник веткой

Каков наилучший способ сделать одну из ветвей репозитория subversion новой соединительной линии?

Для всей системы был внесен большой переписчик: все было перемещено, переписано, заменено, удалено, переименовано и т.д. Переписанный код был протестирован и готов заменить старый багажник.

В принципе, старая магистраль (Trunk 5) помечена и будет завершена здесь. Переписанная ветвь (ветвь 6) должна стать новой основной линией (Trunk 7):

Trunk(1) --> Trunk(2) --> Trunk(5) --> ×          +--> new Trunk(7)
  \                             \                 |
  fork                         merge             ???
    \                             \               |
     +--> Branch(3) --> Branch(4) --> Branch(6) --+

Все текущие изменения со старой "Trunk" уже включены в "Переписанную ветку"

Как я могу это сделать?

ОТВЕТЫ

Ответ 1

Используйте svn move, чтобы переместить содержимое старого ствола куда-нибудь еще, а потом переименовать ветвь в ствол.

Обратите внимание, что копирование и перемещение в SVN работают как файловые операции. Вы можете использовать их для перемещения/копирования материала в вашем хранилище, и эти изменения также имеют версии. Думайте о "переместить" как "копировать + удалить".

[EDIT] Nilbus только что уведомил меня, что вы получите конфликты слияний при использовании svn move.

Я все еще думаю, что это правильный подход. Это приведет к конфликтам, но если вы будете аккуратно сливаться, скорее всего, вы не потеряете данные. Если это вас беспокоит, используйте лучшие VCS, такие как Mercurial или Git.

Ответ 2

Я согласен с использованием команды svn move для достижения этой цели.

Я знаю, что другие здесь считают его необычным, но мне нравится делать это таким образом. Когда у меня есть ветвь признаков и я готов объединить ее с сундуком, который также будет значительно изменен, я объединю его с новой ветвью, обычно называемой <FeatureBranchName>-Merged. Затем я разрешаю конфликты и проверяю объединенный код. После этого я перехожу к багажнику в папку тегов, чтобы ничего не потерять. Наконец, я перемещаю свой <FeatureBranchName>-Merged в багажник.

Кроме того, я предпочитаю избегать рабочей копии при выполнении ходов, вот примеры команд:

svn move https://SVNUrl/svn/Repo/trunk https://SVNUrl/svn/Repo/tags/AnyName

svn move https://SVNUrl/svn/Repo/branches/BranchName-Merged https://SVNUrl/svn/Repo/trunk

Примечание. Я использую 1,5

Ответ 3

Я недавно рассматривал эту проблему, и решение, в котором я был очень доволен, выполнял

svn merge --ignore-ancestry trunk-url branch-url

на рабочей копии моего ствола.

Это не пытается применять изменения в исторической манере (поддерживая изменения в багажнике). Он просто "применяет diff" между стволом и ветвью. Это не создаст конфликтов для ваших пользователей в файлах, которые не были изменены. Однако вы потеряете свою историческую информацию из ветки, но это произойдет, когда вы все равно производите слияние.

Ответ 4

Рекомендуем вам выполнить эти изменения с помощью инструмента браузера репозитория.

Попытка больших операций удаления + перемещения с помощью рабочей копии - отличный способ убить рабочую копию. Если вы вынуждены использовать рабочую копию, выполните инкрементные фиксации после каждой операции удаления или перемещения и ОБНОВЛЯЙТЕ свою рабочую копию после каждой фиксации.

Ответ 5

@Решения Aaron Digulla и @kementeus являются работоспособными. Для репозиториев Subversion 1.4 операции копирования/перемещения могут переносить будущую миграцию в другую структуру репозитория или затруднять разделение репозиториев.

Я считаю, что 1.5 улучшения включают лучшее разрешение истории перемещения/копирования, поэтому, вероятно, это не проблема для хранилища 1.5.

Для репозитория 1.4 я бы рекомендовал использовать svnadmin dump и svndumpfilter для выполнения перемещения существующей магистрали в другом месте, а затем переместить ветку в туловище с тем же механизмом. Загрузите два файла дампа в тестовый репозиторий, проверьте, а затем переместите его в производство.

Конечно, создайте резервную копию существующего репозитория перед запуском.

Это сохраняет историю без явной записи записи/копирования и облегчает будущую реорганизацию, сохраняя историю.

Изменить: по запросу документация о поведении 1.4 из книги 1.4 Red- Bean История хранилища фильтров

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

Это относится к миграции/реорганизации с помощью svndumpfilter. Бывают случаи, когда небольшая дополнительная работа теперь может сэкономить много дополнительной работы позже, а благодаря удобному использованию svndumpfilter, доступного для будущих миграций/реорганизаций, снижает риск при относительно низких затратах.

Ответ 6

Если вы хотите сделать веткой новую магистраль (т.е.) избавиться от всех изменений в сундуке, которые были сделаны с момента создания ветки, вы могли бы 1. Создайте ветвь соединительной линии (для целей резервного копирования) 2. "вернуть изменения" на соединительной линии (выберите все изменения после создания ветки 3. Слейте ветку обратно в ствол.

История должна оставаться такой.

С уважением, Роджер

Ответ 7

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

Независимо от того, какая версия Subversion вы используете, однако, есть метод наилучшей практики для получения изменений в ветке обратно в багажник. Он описан в руководстве Subversion: "Управление версиями с Subversion" , глава 4. Ветвление и слияние, сохранение ветки в синхронизации.

Ответ 8

Это действительно странная/необычная конфигурация в SVN, даже я думаю, что это далеко не совсем "хорошая практика", во всяком случае, я думаю, вы могли бы сделать что-то вроде:

  • Оформить заказ всех sourcetree (svn co therootsourcetree)
  • Удалите соединительную линию (svn rm trunk)
  • Скопируйте ветвь в магистраль (svn cp branch/thebranch/trunk)
  • Удалите ветвь (svn rm branch/thebranch)
  • Зафиксировать изменения

Удачи.