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

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

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

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

Ствол (1) -> Ствол (2) -> Ствол (5) -> × + -> новый Ствол (7)
  \ \ |
  вилка слияния ???
    \ \ |
     + -> Ветвь (3) -> Ветвь (4) -> Ветвь (6) - +

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

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

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

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

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

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

Я согласен с использованием команды 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

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

svn merge --ignore-родословная транк-URL

на рабочей копии моего багажника.

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

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

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

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

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

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

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

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

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

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

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

Удачи