it-swarm.com.ru

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

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

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

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

 Ствол (1) -> Ствол (2) -> Ствол (5) -> × + -> новый Ствол (7) 
\\ | 
 Fork объединить ??? 
\\ | 
 + -> Ветвь (3) -> Ветвь (4) -> Ветвь (6) - + 

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

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

151
Jacco

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

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

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

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

117
Aaron Digulla

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

65
Ryan Cook

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

svn merge --ignore-родословная ствола-url ответвление-url

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

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

12
user349819

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

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

8
Chris Nava

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

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

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

3
rboerdijk

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

3
Ken Gentle

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

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

2
chopp3r