SVN: заменить ствол с ответвлением

Question

Каков наилучший способ сделать одну из ветвей хранилища Subversion новым стволом?

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

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

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

Все текущие изменения из старого «Ствола» уже включены в «Переписанный филиал»

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

Answer 1

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

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

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

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

Answer 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

Answer 3

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

svn merge --ignore-наследственный URL-адрес ствола-URL

на рабочей копии моего сундука.

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

Answer 4

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

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

Answer 5

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

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

С уважением, Roger

Answer 6

@ Решения 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, доступное для будущих миграций / реорганизаций, снижает риск при относительно низкой стоимости.

Answer 7

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

Независимо от того, какую версию Subversion вы используете, тем не менее, существует лучший метод для получения изменений в ветви обратно в транк. Это описано в руководстве Subversion: Контроль версий с Subversion, Глава 4. Ветвление и слияние, синхронизация ветвлений .

Answer 8

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

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

Удачи