Каков наилучший способ сделать одну из ветвей хранилища Subversion новым стволом?
Была проведена большая перезапись всей системы: все было перемещено, переписано, заменено, удалено, переименовано и т. Д. Переписанный код был протестирован и готов заменить старый ствол.
По сути, старая магистраль (магистраль 5) помечена и заканчивается здесь. Переписанная ветвь (ветвь 6) станет новой магистралью (ствол 7):
Ствол (1) -> Ствол (2) -> Ствол (5) -> × + -> новый Ствол (7)
\ \ |
вилка слияния ???
\ \ |
+ -> Ветвь (3) -> Ветвь (4) -> Ветвь (6) - +
Все текущие изменения из старого «Ствола» уже включены в «Переписанный филиал»
Как я могу это сделать?
svn
version-control
Jacco
источник
источник
Я согласен с использованием команды svn move для достижения этой цели.
Я знаю, что другие здесь думают, что это необычно, но мне нравится делать это таким образом. Когда у меня есть ветвь функций, и я готов объединить ее со стволом, который также был значительно изменен, я объединю его с новой веткой, обычно называемой
<FeatureBranchName>-Merged. Затем я разрешаю конфликты и проверяю объединенный код. После этого я перемещаю транк в папку тегов, чтобы ничего не потерять. Наконец я перехожу<FeatureBranchName>-Mergedк багажнику.Кроме того, я предпочитаю избегать рабочей копии при выполнении ходов, вот примеры команд:
Примечание: я использую 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, Фильтрация истории репозитория
Это относится к миграции / реорганизации с использованием
svndumpfilter. Бывают случаи, когда небольшая дополнительная работа может сэкономить большую часть дополнительной работы, а простое использованиеsvndumpfilterдоступных для будущих миграций / реорганизаций снижает риск при относительно низких затратах.источник
Хотя приведенные выше ответы будут работать, они не являются лучшей практикой. Последний трек svn server и client объединяет для вас. Svn знает, какие ревизии вы слили в ветку и откуда. Это очень помогает, когда ветка обновляется, а затем сливается обратно в ствол.
Независимо от того, какую версию Subversion вы используете, тем не менее, существует лучший метод возврата изменений в ветку в транк. Он описан в руководстве Subversion: Контроль версий с Subversion, Глава 4. Ветвление и слияние, Синхронизация ветвления .
источник
Это действительно странная / необычная конфигурация в SVN, даже я думаю, что это вовсе не «хорошая практика», во всяком случае, я думаю, вы могли бы сделать что-то вроде:
Удачи
источник