git-svn — Двунаправленная работа между репозиторием Subversion и Git

git svn — это простой конвейер для наборов изменений между Subversion и Git. Он обеспечивает двунаправленный поток изменений между репозиториями Subversion и Git.

git svn может отслеживать стандартный репозиторий Subversion, следуя распространённой структуре "trunk/branches/tags", с опцией --stdlayout. Он также может отслеживать ветки и метки в любой структуре с помощью опций -T/-t/-b (см. опции init ниже, а также команду clone).

После начала отслеживания репозитория Subversion (любым из вышеперечисленных методов) репозиторий Git может быть обновлён из Subversion с помощью команды fetch, а Subversion обновлён из Git с помощью команды dcommit.

Поскольку параметры noMetadata, rewriteRoot, rewriteUUID, useSvnsyncProps и useSvmProps влияют на метаданные, генерируемые и используемые git svn; они должны быть установлены в файле конфигурации до импорта какой-либо истории, и эти настройки никогда не должны изменяться после их установки.

Кроме того, в разделе svn-remote можно использовать только один из этих параметров, поскольку они влияют на строку метаданных git-svn-id:, за исключением rewriteRoot и rewriteUUID, которые можно использовать вместе.

Отслеживание и участие в разработке основной ветки (trunk) проекта, управляемого Subversion (игнорируя метки и ветки):

Отслеживание и участие в разработке всего проекта, управляемого Subversion (полностью с основной веткой, метками и ветками):

Начальный git svn clone может быть довольно трудоёмким (особенно для больших репозиториев Subversion). Если несколько человек (или один человек с несколькими машинами) хотят использовать git svn для взаимодействия с одним и тем же репозиторием Subversion, вы можете выполнить начальный git svn clone в репозиторий на сервере и позволить каждому человеку клонировать этот репозиторий с помощью git clone:

Предпочтительнее использовать git svn rebase или git rebase, а не git pull или git merge для синхронизации неинтегрированных коммитов с веткой git svn. Это сохранит историю неинтегрированных коммитов линейной относительно вышестоящего (upstream) репозитория SVN и позволит использовать предпочтительную подкоманду git svn dcommit для отправки неинтегрированных коммитов обратно в SVN.

Изначально git svn рекомендовал разработчикам выполнять pull или merge из ветки git svn. Это произошло потому, что автор предпочитал git svn set-tree B для фиксации одной головы, а не обозначение git svn set-tree A..B для фиксации нескольких коммитов. Использование git pull или git merge с git svn set-tree A..B приведёт к уплощению нелинейной истории при фиксации в SVN, и это может привести к тому, что коммиты слияния неожиданно отменят предыдущие коммиты в SVN.

Хотя git svn может отслеживать историю копирования (включая ветки и метки) для репозиториев, использующих стандартную структуру, он пока не может представить историю слияний, произошедших внутри git, обратно вышестоящим (upstream) пользователям SVN. Поэтому рекомендуется, чтобы пользователи сохраняли историю в Git максимально линейной для облегчения совместимости с SVN (см. раздел ПРЕДОСТЕРЕЖЕНИЯ ниже).

Если git svn настроен на получение веток (и действует --follow-branches), он иногда создаёт несколько веток Git для одной ветки SVN, причём дополнительные ветки имеют имена вида имя-ветки@nnn (где nnn — номер редакции SVN). Эти дополнительные ветки создаются, если git svn не может найти родительский коммит для первого коммита в ветке SVN, чтобы соединить ветку с историей других веток.

Обычно первый коммит в ветке SVN состоит из операции копирования. git svn прочитает этот коммит, чтобы получить редакцию SVN, из которой была создана ветка. Затем он попытается найти коммит Git, соответствующий этой редакции SVN, и использовать его в качестве родителя ветки. Однако возможно, что нет подходящего коммита Git, который мог бы служить родителем. Это произойдёт, среди прочих причин, если ветка SVN является копией редакции, которая не была получена git svn (например, потому что это старая редакция, пропущенная с помощью --revision), или если в SVN был скопирован каталог, который не отслеживается git svn (например, ветка, которая вообще не отслеживается, или подкаталог отслеживаемой ветки). В этих случаях git svn всё равно создаст ветку Git, но вместо использования существующего коммита Git в качестве родителя ветки он прочитает историю SVN каталога, из которого была скопирована ветка, и создаст соответствующие коммиты Git. На это указывает сообщение "Initializing parent: <имя-ветки>".

Кроме того, он создаст специальную ветку с именем <имя-ветки>@<SVN-Редакция>, где <SVN-Редакция> — это номер редакции SVN, из которой была скопирована ветка. Эта ветка будет указывать на вновь созданный родительский коммит ветки. Если в SVN ветка была удалена, а затем воссоздана из другой версии, будет несколько таких веток с символом @.

Обратите внимание, что это может означать, что для одной редакции SVN создаётся несколько коммитов Git.

Пример: в репозитории SVN со стандартной структурой trunk/tags/branches каталог trunk/sub создаётся в r.100. В r.200 trunk/sub ответвляется путём копирования в branches/. git svn clone -s затем создаст ветку sub. Он также создаст новые коммиты Git для r.100 - r.199 и использует их как историю ветки sub. Таким образом, для каждой редакции с r.100 по r.199 будет два коммита Git (один, содержащий trunk/, и один, содержащий trunk/sub/). Наконец, он создаст ветку sub@200, указывающую на новый родительский коммит ветки sub (т.е. коммит для r.200 и trunk/sub/).

Ради простоты и совместимости с Subversion рекомендуется, чтобы все пользователи git svn клонировали, получали (fetch) и выполняли dcommit непосредственно с сервера SVN и избегали всех операций git clone/pull/merge/push между репозиториями и ветками Git. Рекомендуемый метод обмена кодом между ветками и пользователями Git — это git format-patch и git am, или просто выполнение dcommit в репозиторий SVN.

Выполнение git merge или git pull НЕ рекомендуется в ветке, из которой вы планируете выполнять dcommit, потому что пользователи Subversion не видят никаких сделанных вами слияний. Кроме того, если вы выполняете merge или pull из ветки Git, которая является зеркалом ветки SVN, dcommit может зафиксировать изменения в неправильной ветке.

Если вы всё же выполняете слияние, обратите внимание на следующее правило: git svn dcommit попытается зафиксировать изменения поверх коммита SVN, указанного в

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

git clone не клонирует ветки в иерархии refs/remotes/, а также любые метаданные или конфигурацию git svn. Поэтому репозитории, созданные и управляемые с помощью git svn, должны использовать rsync для клонирования, если клонирование вообще необходимо.

Поскольку dcommit внутренне использует rebase, любые ветки Git, в которые вы выполняете git push до dcommit, потребуют принудительной перезаписи существующей ссылки во внешнем репозитории. Это обычно считается плохой практикой; подробности см. в документации git-push[1].

Не используйте опцию --amend команды git-commit[1] для изменения, которое вы уже зафиксировали с помощью dcommit. Считается плохой практикой использовать --amend для коммитов, которые вы уже отправили во внешний репозиторий для других пользователей, и dcommit с SVN аналогичен этому.

При клонировании репозитория SVN, если не используется ни одна из опций для описания структуры репозитория (--trunk, --tags, --branches, --stdlayout), git svn clone создаст репозиторий Git с полностью линейной историей, где ветки и метки отображаются как отдельные каталоги в рабочей копии. Хотя это самый простой способ получить копию полного репозитория, для проектов со многими ветками это приведёт к рабочей копии, во много раз превышающей размер только основной ветки (trunk). Таким образом, для проектов, использующих стандартную структуру каталогов (trunk/branches/tags), рекомендуется клонировать с опцией --stdlayout. Если проект использует нестандартную структуру и/или если ветки и метки не требуются, проще всего клонировать только один каталог (обычно trunk), не указывая никаких опций структуры репозитория. Если требуется полная история с ветками и метками, необходимо использовать опции --trunk / --branches / --tags.

При использовании нескольких --branches или --tags git svn не обрабатывает автоматически коллизии имён (например, если две ветки из разных путей имеют одинаковое имя или если ветка и метка имеют одинаковое имя). В этих случаях используйте init для настройки вашего репозитория Git, затем, перед первым fetch, отредактируйте файл $GIT_DIR/config, чтобы ветки и метки были связаны с разными пространствами имён. Например:

git svn хранит информацию о конфигурации [svn-remote] в файле $GIT_DIR/config репозитория. Это похоже на разделы [remote] ядра Git, за исключением того, что ключи fetch не принимают glob-аргументы; вместо этого они обрабатываются ключами branches и tags. Поскольку некоторые репозитории SVN имеют необычную конфигурацию с несколькими проектами, разрешены glob-расширения, такие как перечисленные ниже:

Имейте в виду, что wildcard-символ * (звёздочка) локальной ссылки (справа от :) должен быть самым правым компонентом пути; однако внешний wildcard может быть где угодно, если он является независимым компонентом пути (окружённым / или концом строки). Этот тип конфигурации не создаётся автоматически командой init и должен быть введён вручную с помощью текстового редактора или с использованием git config.

Также обратите внимание, что в слове разрешена только одна звёздочка. Например:

будет соответствовать веткам release, rese, re123se, однако

выдаст ошибку.

Также возможно получить подмножество веток или меток, используя разделённый запятыми список имён в фигурных скобках. Например:

Поддерживаются несколько ключей fetch, branches и tags:

Создание ветки в такой конфигурации требует устранения неоднозначности относительно того, какое местоположение использовать, с помощью флага -d или --destination:

Обратите внимание, что git-svn отслеживает самую высокую редакцию, в которой появилась ветка или метка. Если подмножество веток или меток изменяется после получения (fetch), то файл $GIT_DIR/svn/.metadata должен быть отредактирован вручную, чтобы удалить (или сбросить) branches-maxRev и/или tags-maxRev по соответствию.

Мы игнорируем все свойства SVN, кроме svn:executable. Любые необработанные свойства записываются в журнал $GIT_DIR/svn/<имя-ссылки>/unhandled.log

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

В SVN возможно (хотя и не рекомендуется) фиксировать изменения в метке (поскольку метка — это просто копия каталога, и, следовательно, технически то же самое, что и ветка). При клонировании репозитория SVN git svn не может знать, произойдёт ли такая фиксация в метку в будущем. Поэтому он действует консервативно и импортирует все метки SVN как ветки, добавляя к имени метки префикс tags/.

git-rebase[1]

Является частью пакета git[1]