Поделиться через

Узнайте, как перейти из Subversion (SVN) в Git, включая журнал

Azure DevOps Services | Azure DevOps Server 2022 — Azure DevOps Server 2019

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

Миграции SVN в Git могут отличаться в зависимости от того, сколько лет репозиторий создан и сколько ветвей было создано и объединено, и независимо от того, используется ли обычный SVN или близкий, как SVK.

Это может быть просто, если:

  • У вас есть новый репозиторий
  • У вас есть стандартная настройка каталога магистралей, ветвей и тегов

Скорее всего, это будет сложно, если:

  • Ваша команда выполнила множество операций ветвления и объединения
  • Репозиторий следует настройке нестандартного каталога
  • Настройка каталога изменилась с течением времени

Существует несколько способов миграции из SVN в Git. Подход, описанный в этой статье, основан на использовании git-svn, расширения Git, который можно использовать для получения репозитория Subversion в локальный репозиторий Git, а затем отправки изменений из локального репозитория Git обратно в репозиторий Subversion. Эти действия содержат подробный обзор процесса миграции с SVN в Git в среде Windows без синхронизации с исходным репозиторием SVN. Результатом будет голый репозиторий Git для совместного использования с остальной частью вашей команды.

Примечание.

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

Высокоуровневый рабочий процесс миграции из SVN в Git выглядит следующим образом:

  • Подготовка среды миграции
  • Преобразование исходного репозитория SVN в локальный репозиторий Git
  • (Необязательно) Синхронизация локального репозитория Git с любыми изменениями из репозитория SVN, пока разработчики продолжают использовать SVN
  • Отправка локального репозитория Git в удаленный репозиторий Git, размещенный в Azure Repos
  • Блокировка репозитория SVN, синхронизация оставшихся изменений из репозитория SVN в локальный репозиторий Git и отправка окончательных изменений в удаленный репозиторий Git в Azure Repos
  • Разработчики переключаются на Git в качестве основной системы управления версиями

Подготовка среды миграции

Настройте среду миграции на локальной рабочей станции и установите следующее программное обеспечение:

Вам также потребуется создать репозиторий Git для организации для размещения преобразованного репозитория SVN, вы можете следовать созданию репозитория Git в проекте.

Преобразование исходного репозитория SVN в локальный репозиторий Git

Цель этого шага — преобразовать исходный репозиторий Subversion в локальный репозиторий Git. В простом репозитории Git нет локальной рабочей проверки файлов, которые могут быть изменены, вместо этого он содержит только журнал репозитория и метаданные о самом репозитории. Это рекомендуемый формат для совместного использования репозитория Git с помощью удаленный репозиторий, размещенной в службе, такой как Azure Repos.

Совет

Репозитории Git структурированы по-разному и учитывая тот факт, что у него нет рабочего каталога, предотвращают прямую фиксацию в репозитории.

Репозиторий Git

Получение списка всех авторов Subversion

Подверсия просто использует имя пользователя для каждой фиксации, а Git сохраняет как реальное имя, так и адрес электронной почты. По умолчанию средство git-svn выводит имя пользователя SVN в полях автора и электронной почты. Однако вы можете создать файл сопоставления для пользователей SVN вместе с соответствующими именами и электронными письмами Git.

Пользователи подверсии

Пользователи подверсии

Пользователи Git

Пользователи Git

Чтобы извлечь список всех пользователей SVN из корневого каталога локальной проверки subversion, выполните следующую команду PowerShell:

Для получения результатов utf8NoBOM кодирования выполните следующую команду:

svn.exe log --quiet | ? { $_ -notlike '-*' } | % { "{0} = {0} " -f ($_ -split ' | ')[1] } | Select-Object -Unique | Sort-Object | Out-File 'authors-transform.txt' -Encoding utf8NoBOM

Для получения результатов ASCII кодирования выполните следующую команду:

svn.exe log --quiet | ? { $_ -notlike '-*' } | % { "{0} = {0} " -f ($_ -split ' | ')[1] } | Select-Object -Unique | Sort-Object | Out-File 'authors-transform.txt' -Encoding ASCII

Эта команда извлекает все сообщения журнала, извлекает имена пользователей, устраняет повторяющиеся имена пользователей, сортирует имена пользователей и помещает их в файл authors-transform.txt в формате UTF-8 (или в формате ASCII в зависимости от указанного кодировки). Затем можно изменить каждую строку в файле, чтобы создать сопоставление пользователей SVN с хорошо отформатированными пользователями Git. Например, можно сопоставить jamal = Jamal Hartnett <jamal@fabrikam-fiber.com>с jamal = jamal <jamal> .

Клонирование репозитория Subversion с помощью git-svn

Следующая команда выполнит стандартное преобразование git-svn с помощью файла authors-transform.txt, созданного на предыдущем шаге. Он поместит репозиторий Git в папку c:\mytempdir на локальном компьютере.

git svn clone ["SVN repo URL"] --prefix=svn/ --no-metadata --authors-file "authors-transform.txt" --stdlayout c:\mytempdir

Примечание.

Это --prefix=svn/ необходимо, так как в противном случае средства не могут сообщать редакциям SVN из импортированных. Рекомендуется задать префикс (с косой чертой), так как ссылки на отслеживание SVN будут находиться по refs/remotes/$prefix/адресу, который совместим с собственным макетом ветви удаленного отслеживания Git (refs/remotes/$remote/).

Настройка префикса также полезна, если вы хотите отслеживать несколько проектов, которые совместно используют общий репозиторий. По умолчанию префикс имеет значение origin/.

Если вы используете стандартную магистраль, ветви, макет тегов, вы просто поместите --stdlayout. Тем не менее, если у вас есть что-то другое, возможно, вам придется пройти --trunk, --branchesи --tags найти то, что такое. Например, если структура репозитория была trunk/companydir ветвленной, а не магистральной, скорее всего, потребуется --trunk=trunk/companydir --branches=branches.

git svn clone ["SVN repo URL"] --prefix=svn/ --no-metadata --trunk=/trunk --branches=/branches --tags=/tags  --authors-file "authors-transform.txt" c:\mytempdir

Примечание.

Эта команда может занять несколько минут до нескольких часов в зависимости от размера репозитория SVN. После завершения вы получите проверку Git репозитория.

Преобразование конфигураций, относящихся к управлению версиями

Если репозиторий SVN использовал свойства svn:ignore, можно преобразовать в файл gitignore с помощью:

cd c:\mytempdir
git svn show-ignore --id=origin/trunk > .gitignore
git add .gitignore
git commit -m 'Convert svn:ignore properties to .gitignore.'

Совет

Дополнительные сведения о .gitignore: игнорировать изменения файла с помощью Git

Отправка репозитория в простой репозиторий Git

На этом шаге вы создадите голый репозиторий и сделайте его ветвь по умолчанию совпадать с именем магистрали SVN.

  1. Создание простого репозитория Git

    git init --bare c:\new-bare.git
cd c:\new-bare.git
git symbolic-ref HEAD refs/heads/svn/trunk

  2. Отправка локального репозитория Git в новый репозиторий Git

    cd c:\mytempdir 
git remote add bare c:\new-bare.git 
git config remote.bare.push refs/remotes/*:refs/heads/* 
git push bare

  3. Переименуйте ветвь trunk mainв . Основная ветвь разработки будет называться "магистраль", которая соответствует имени, которое было в Subversion. Вы хотите переименовать его в стандартную main ветвь Git с помощью:

    cd c:\new-bare.git
git branch -m svn/trunk main

  4. Очистка ветвей и тегов git-svn делает все теги Subversions в очень короткие ветви в Git формы "теги/имя". Вы хотите преобразовать все эти ветви в фактические теги Git или удалить их.

Перенос тегов SVN в теги Git

cd c:\new-bare.git
git for-each-ref --format='%(refname)' refs/heads/svn/tags | % { $_.Replace('refs/heads/svn/tags/','') } | % { git tag $_ "refs/heads/svn/tags/$_"; git branch -D "svn/tags/$_" }

Расширенные миграции

Создание всех ветвей SVN в качестве соответствующих ветвей Git

Хотя легко создать все ветви SVN в качестве соответствующих ветвей Git, рекомендуется оценить следующие моменты перед продолжением.

  • Если есть ветви компонентов: можно ждать, пока они не интегрируются в магистраль перед переносом?

  • Если существуют ветви выпуска: имеет ли смысл сохранить SVN для обслуживания? Если вы переносите ветвь компонента, вы готовы к обслуживанию ветвей из Git?

Если вы по-прежнему хотите перенести существующие ветви, выполните следующую команду PowerShell:

git for-each-ref --format='%(refname)' refs/remotes | % { $_.Replace('refs/remotes/','') } | % { git branch "$_" "refs/remotes/$_"; git branch -r -d "$_"; }

Примечание.

Эта команда может занять несколько минут до нескольких часов в зависимости от размера репозитория SVN. После завершения вы получите проверку Git репозитория.

Перенос только определенных редакций

Если этот параметр не указан, git-svn clone перенесите все редакции из первой фиксации (r1) в HEAD. Если вам нужно перенести только определенный набор исправлений, команда должна git-svn clone быть добавлена с параметром -r.

Например, если необходимо выполнить миграцию с ред. 100 на HEAD, команда выглядит следующим образом:

git svn clone ["SVN repo URL"] --prefix=svn/ --no-metadata --authors-file "authors-transform.txt" --stdlayout c:\mytempdir -r100:HEAD

Обновление рабочего процесса

Переход от централизованной системы управления версиями к Git больше, чем просто перенос кода. Ваша команда нуждается в обучении, чтобы понять, как Git отличается от существующей системы управления версиями и как эти различия влияют на повседневную работу. Подробнее.

Справочные сведения

Авторы: Хосам Камель, Уильям Х. Салазар | Найдите источник этой статьи и подключитесь к ALM | Руководство по ветви DevOps Rangers

(c) Корпорация Майкрософт 2017 г. Все права защищены. Этот документ предоставляется как есть. Сведения и представления, выраженные в этом документе, включая URL-адрес и другие ссылки на веб-сайт Интернета, могут изменяться без уведомления. Вы берете на себя все риски, связанные с использованием сведений, приводящихся в данном документе.

Этот документ не предоставляет никаких юридических прав на любую интеллектуальную собственность в любом продукте Майкрософт. Этот документ можно копировать и использовать только для внутренних справочных целей.