українська мова ▾ Topics ▾ Latest version ▾ git-svn last updated in 2.52.0

НАЗВА

git-svn — Двосторонній обмін даними між репозиторієм Subversion та Git

СИНОПСИС

git svn <command> [<options>] [<arguments>]

ОПИС

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.

КОМАНДИ

init

Ініціалізує порожній репозиторій Git з додатковими теками метаданих для git svn. URL-адресу Subversion можна вказати як аргумент командного рядка або як повні аргументи URL-адреси для -T/-t/-b. За потреби, цільову теку для роботи можна вказати як другий аргумент. Зазвичай ця команда ініціалізує поточну теку.

-T<trunk-subdir>
--trunk=<trunk-subdir>
-t<tags-subdir>
--tags=<tags-subdir>
-b<branches-subdir>
--branches=<branches-subdir>
-s
--stdlayout

Це необовʼязкові параметри командного рядка для init. Кожен із цих прапорців може вказувати на відносний шлях до репозиторію (--tags=project/tags) або повну URL-адресу (--tags=https://foo.org/project/tags). Ви можете вказати більше одного параметра --tags та/або --branches, якщо ваш репозиторій Subversion розміщує теги або гілки за кількома шляхами. Параметр --stdlayout — це скорочений спосіб встановлення trunk,tags,branches як відносних шляхів, що є стандартним значенням Subversion. Якщо також вказано будь-які інші параметри, вони мають пріоритет.

--no-metadata

Встановлює параметр noMetadata у конфігурації [svn-remote]. Цей параметр не рекомендується використовувати; перед його застосуванням, будь ласка, ознайомтеся з розділом svn.noMetadata цієї сторінки довідки.

--use-svm-props

Встановити опцію useSvmProps у конфігурації [svn-remote].

--use-svnsync-props

Встановити опцію useSvnsyncProps у конфігурації [svn-remote].

--rewrite-root=<URL>

Встановити опцію rewriteRoot у конфігурації [svn-remote].

--rewrite-uuid=<UUID>

Встановити опцію rewriteUUID у конфігурації [svn-remote].

--username=<user>

Для транспортів, для яких SVN обробляє автентифікацію (http, https та звичайний svn), вкажіть імʼя користувача. Для інших транспортів (наприклад, svn+ssh://) необхідно включити імʼя користувача до URL-адреси, наприклад, svn+ssh://foo@svn.bar.com/project

--prefix=<prefix>

Дозволяє вказати префікс, який додається до імен віддалених репозиторіїв, якщо вказано trunk/branches/tags. Префікс автоматично не містить кінцевого слеша, тому переконайтеся, що ви додали його в аргумент, якщо це необхідно. Якщо вказано --branches/-b, префікс повинен містити кінцеву косу риску. У будь-якому випадку наполегливо рекомендується встановити префікс (з кінцевою скісною рискою), оскільки ваші посилання для відстеження SVN будуть розташовані в «refs/remotes/$prefix/», що сумісно з власною структурою посилань для відстеження віддалених репозиторіїв у Git (refs/remotes/$remote/). Встановлення префікса також корисно, якщо ви хочете відстежувати кілька проєктів, які використовують спільне сховище. Стандартно префікс встановлено як origin/.

Note
 До версії Git версії 2.0 стандартним префіксом був "" (без префікса). Це означало, що посилання для SVN-відстеження розміщувалися в "refs/remotes/*", що несумісно з тим, як організовані власні посилання для віддаленого відстеження Git. Якщо ви все ще хочете використовувати старе стандартне значення, ви можете отримати його, передавши --prefix "" у командному рядку (--prefix="" може не працювати, якщо ваш Getopt::Long Perl < версії 2.37).
--ignore-refs=<regex>

При передачі до init або clone цей регулярний вираз буде збережено як ключ конфігурації. Див. fetch для опису --ignore-refs.

--ignore-paths=<regex>

При передачі до init або clone цей регулярний вираз буде збережено як ключ конфігурації. Див. fetch для опису --ignore-paths.

--include-paths=<regex>

При передачі до init або clone цей регулярний вираз буде збережено як ключ конфігурації. Див. fetch для опису --include-paths.

--no-minimize-url

Під час відстеження декількох тек (за допомогою опцій --stdlayout, --branches або --tags) git svn намагатиметься підключитися до кореня (або найвищого дозволеного рівня) репозиторію Subversion. Це стандартне налаштування забезпечує краще відстеження історії, якщо цілі проєкти переміщуються в межах одного репозиторію, але може спричинити проблеми в репозиторіях, де встановлено обмеження на читання. Передача --no-minimize-url дозволить git svn приймати URL-адреси такими, як вони є, без спроб підключення до каталогу вищого рівня. Ця опція стандартно вимкнена, коли відстежується лише одна URL-адреса/гілка (вона не дасть особливої користі).

fetch

Завантажити ще не завантажені версії з віддаленого сервера Subversion, за яким ми стежимо. Імʼя розділу [svn-remote "…​"] у файлі $GIT_DIR/config можна вказати як необовʼязковий аргумент командного рядка.

Це автоматично оновлює rev_map за потреби (див. $GIT_DIR/svn/**/.rev_map.* у розділі ФАЙЛИ нижче для отримання детальнішої інформації).

--localtime

Зберігати час комітів Git у місцевому часовому поясі, а не в UTC. Завдяки цьому команда git log (навіть без параметра --date=local) відображатиме той самий час, що й svn log у місцевому часовому поясі.

Це не заважає взаємодії з репозиторієм Subversion, з якого ви зробили клонування, але якщо ви хочете, щоб ваш локальний репозиторій Git міг взаємодіяти з локальним репозиторієм Git іншої людини, або не використовуйте цю опцію, або вам обом слід використовувати той самий місцевий часовий пояс.

--parent

Завантажувати лише з батьківського репозиторію SVN поточного HEAD.

--ignore-refs=<regex>

Ігнорувати посилання на гілки або теги, що відповідають регулярному виразу Perl. Для допуску лише певних посилань можна використовувати «негативне попереднє твердження», наприклад: ^refs/remotes/origin/(?!tags/wanted-tag|wanted-branch).*$.

config key: svn-remote.<name>.ignore-refs

Якщо встановлено ключ конфігурації ignore-refs, а також задано параметр командного рядка, будуть використані обидва регулярні вирази.

--ignore-paths=<regex>

Це дозволяє вказати регулярний вираз Perl, який забезпечить пропуск усіх відповідних шляхів під час завантаження з SVN. Параметр --ignore-paths повинен застосовуватися до кожного виклику команди fetch (включно з автоматичними завантаженнями, що відбуваються під час виконання команд clone, dcommit, rebase тощо) у вказаному репозиторії.

config key: svn-remote.<name>.ignore-paths

Якщо встановлено ключ конфігурації ignore-paths, а також задано параметр командного рядка, будуть використані обидва регулярні вирази.

Приклади:

Пропускати теку "doc*" для кожного завантаження 
--ignore-paths="^doc"
Пропускати "гілки" та "теги" тек першого рівня 
--ignore-paths="^[^/]+/(?:branches|tags)"
--include-paths=<regex>

Це дозволяє вказати регулярний вираз Perl, який призведе до включення лише відповідних шляхів з завантаження з SVN. Опція --include-paths повинна збігатися для кожної вибірки (включаючи автоматичні вибірки через clone, dcommit, rebase тощо) у заданому репозиторії. --ignore-paths має пріоритет над --include-paths.

config key: svn-remote.<name>.include-paths
--log-window-size=<n>

Отримувати <n> записів журналу на запит під час сканування історії Subversion. Стандартне значення — 100. Для дуже великих репозиторіїв Subversion можуть знадобитися більші значення, щоб clone/fetch завершилися за прийнятний час. Але занадто великі значення можуть призвести до більшого використання пам’яті та затримок запитів.

clone

Виконує команди init та fetch. Автоматично створює теку на основі базового імені URL-адреси, що передається їй; або, якщо передано другий аргумент, створює теку та працює в ній. Приймає всі аргументи, які приймають команди init та fetch, за винятком --fetch-all та --parent. Після клонування репозиторію команда fetch зможе оновлювати ревізії, не впливаючи на робоче дерево, а команда «rebase» зможе оновлювати робоче дерево з урахуванням останніх змін.

--preserve-empty-dirs

Створить файл-заповнювач у локальному репозиторії Git для кожної порожньої теки, отриманої з Subversion. Це включає теки, які стають порожніми внаслідок видалення всіх записів у репозиторії Subversion (але не самої теки). Файли-заповнювачі також відстежуються та видаляються, коли вони більше не потрібні.

--placeholder-filename=<filename>

Встановити назву файлів-заповнювачів, створених за допомогою --preserve-empty-dirs. Стандартно — ".gitignore"

rebase

Команда отримує версії з батьківського SVN поточного HEAD та перебазує поточну (незафіксовану в SVN) роботу відносно неї.

Вона працює подібно до svn update або git pull', за винятком того, що для зручності dcomit-утворення за допомогою `git svn' зберігається лінійна історія з `git rebase замість git merge.

Команда приймає всі опції, які приймають git svn fetch та git rebase. Однак, --fetch-all отримує дані лише з поточного [svn-remote], а не з усіх визначень [svn-remote].

Як і git rebase; це вимагає, щоб робоче дерево було чистим і не мало незафіксованих змін.

Це автоматично оновлює rev_map за потреби (див. $GIT_DIR/svn/**/.rev_map.* у розділі ФАЙЛИ нижче для отримання детальнішої інформації).

-l
--local

Не завантажувати дані з віддалених джерел; просто запустити git rebase” для останнього завантаженого коміту з головного SVN-репозиторію.

dcommit

Фіксувати кожну зміну з поточної гілки безпосередньо у сховищі SVN, а потім виконати rebase або reset (залежно від того, чи є розбіжності між SVN і головною гілкою). В результаті для кожного коміту в Git у SVN буде створено ревізію.

Якщо в якості аргументу вказано імʼя гілки Git (або імʼя обʼєкта коміту Git), субкоманда працює з вказаною гілкою, а не з поточною.

Використання dcommit є кращим за set-tree (нижче).

--no-rebase

Після фіксації змін не виконувати rebase чи reset.

--commit-url <URL>

Робить коміт за цією URL-адресою SVN (повний шлях). Це зроблено для того, щоб наявні репозиторії git svn, створені з використанням одного методу передачі даних (наприклад, svn:// або http:// для анонімного читання), можна було використовувати повторно, якщо користувачеві згодом нададуть доступ до іншого методу передачі даних (наприклад, svn+ssh:// або https://) для виконання комітів.

config key: svn-remote.<name>.commiturl
config key: svn.commiturl (overwrites all svn-remote.<name>.commiturl options)

Зверніть увагу, що URL-адреса SVN у параметрі конфігурації commiturl містить назву гілки SVN. Якщо ви бажаєте вказати URL-адресу коміту для всього репозиторію SVN, скористайтеся замість цього параметром svn-remote.<name>.pushurl.

Категорично не рекомендується використовувати цю опцію для будь-яких інших цілей (не питайте).

--mergeinfo=<mergeinfo>

Додає вказану інформацію про злиття під час виконання команди dcommit (наприклад, --mergeinfo="/branches/foo:1-10"). Усі версії сервера SVN можуть зберігати цю інформацію (як властивість), а клієнти SVN, починаючи з версії 1.5, можуть її використовувати. Щоб вказати інформацію про злиття з декількох гілок, використовуйте один пробіл між гілками (--mergeinfo="/branches/foo:1-10 /branches/bar:3,5-6,8")

config key: svn.pushmergeinfo

Ця опція призведе до того, що git-svn намагатиметься автоматично заповнити властивість svn:mergeinfo в репозиторії SVN, коли це можливо. Наразі це можна зробити лише під час dcommitting злиття без швидкого перемотування, де всі батьківські обʼєкти, крім першого, вже були завантажені в SVN.

--interactive

Запитувати користувача підтвердження, що набір латок дійсно має бути надісланий до SVN. Для кожної латки можна відповісти «yes» (прийняти цю латку), «no» (відхилити латки), «all» (прийняти всі латки) або «quit».

git svn dcommit виходить негайно, якщо відповідь «no» або «quit», без жодних комітів до SVN.

branch

Створення гілки в репозиторії SVN.

-m
--message

Дозволяє вказати повідомлення коміту.

-t
--tag

Створює тег, використовуючи tags_subdir замість branches_subdir, вказаного під час ініціалізації git svn.

-d<path>
--destination=<path>

Якщо команді init або clone було надано більше одного параметра --branches (або --tags), ви повинні вказати розташування гілки (або тегу), яку ви хочете створити, у репозиторії SVN. <path> вказує, який шлях використовувати для створення гілки або тегу, і має відповідати шаблону ліворуч від однієї з налаштованих гілок або тегів refspecs. Ви можете побачити ці refspecs за допомогою команд

git config --get-all svn-remote.<name>.branches git config --get-all svn-remote.<name>.tags

де <name> — це назва SVN-репозиторію, як зазначено в опції -R для init (або стандартно — "svn").

--username

Вкажіть ім’я користувача SVN для виконання коміту. Цей параметр замінює властивість конфігурації username.

--commit-url

Використовувати вказану URL-адресу для підключення до цільового репозиторію Subversion. Це корисно у випадках, коли вихідний репозиторій SVN доступний лише для читання. Цей параметр замінює властивість конфігурації commiturl.

git config --get-all svn-remote.<name>.commiturl
--parents

Створити батьківські теки. Цей параметр еквівалентний параметру --parents у командах svn cp і корисний для репозиторіїв з нестандартної структурою.

tag

Створює тег у репозиторії SVN. Це скорочена форма для branch -t.

log

Цей параметр має спростити пошук повідомлень журналу svn, коли користувачі svn вказують номери ревізій за допомогою опції -r або --revision.

Підтримуються такі функції з ‘svn log’:

-r <n>[:<n>]
--revision=<n>[:<n>]

підтримується, нечислові аргументи не підтримуються: HEAD, NEXT, BASE, PREV тощо …​

-v
--verbose

це не повністю сумісно з виводом --verbose в журналі svn, але досить близько.

--limit=<n>

НЕ те саме, що й --max-count, не враховує обʼєднані/виключені коміти

--incremental

підтримується

Нові можливості:

--show-commit

також показує Git-коміт sha1

--oneline

наша версія --pretty=oneline

Note
 Сам SVN зберігає час лише в UTC і нічого більше. Звичайний svn-клієнт конвертує час UTC у місцевий час (або на основі середовища TZ=). Ця команда має таку ж поведінку.

Будь-які інші аргументи передаються безпосередньо до git log

blame

Показує, яка ревізія та автор востаннє змінювали кожен рядок файлу. Вивід цього режиму стандартно сумісний за форматом з виводу ‘svn blame’. Як і команда SVN blame, локальні незафіксовані зміни в робочому дереві ігноруються; версія файлу в ревізії HEAD анотується. Невідомі аргументи передаються безпосередньо до git blame.

--git-format

Виводить результати у тому ж форматі, що й команда git blame, але з номерами ревізій SVN замість хешів комітів Git. У цьому режимі зміни, які ще не зафіксовано в SVN (включно з редагуваннями в локальній робочій копії), відображаються як ревізія 0.

find-rev

Якщо вказано номер ревізії SVN у форматі rN, повертає відповідний хеш коміту Git (за ним можна вказати деревоподібний параметр, щоб вказати, у якій гілці слід здійснювати пошук). Якщо вказано деревоподібний параметр, повертає відповідний номер ревізії SVN.

-B
--before

Не вимагати точного збігу, якщо задана ревізія SVN, натомість знайти коміт, що відповідає стану репозиторію SVN (у поточній гілці) у вказаній ревізії.

-A
--after

Не вимагати точного збігу, якщо задана версія SVN; якщо точного збігу немає, повернути найближчий збіг, шукаючи вперед в історії.

set-tree

Замість цієї команди варто розглянути використання dcommit. Фіксує вказані обʼєкти коміту або дерева до SVN. Це залежить від того, чи є ваші імпортовані дані fetch актуальними. Ця команда абсолютно не намагається виконати виправлення під час коміту до SVN, вона просто перезаписує файли тими, що вказані в дереві або коміті. Вважається, що все злиття відбулося незалежно від функцій git svn.

create-ignore

Рекурсивно знаходить властивості svn:ignore та svn:global-ignores для тек та створює відповідні файли .gitignore. Отримані файли підготовлюються до фіксації, але не фіксуються. Використовуйте -r/--revision для посилання на певну версію.

show-ignore

Рекурсивно знаходить та виводить список властивостей svn:ignore та svn:global-ignores для тек. Вивід можна додавати до файлу $GIT_DIR/info/exclude.

mkdirs

Намагатись відтворити порожні теки, які ядро Git не може відстежувати, на основі інформації з файлів $GIT_DIR/svn/<refname>/unhandled.log. Порожні теки автоматично відтворюються під час використання команд git svn clone та git svn rebase, тому команда mkdirs призначена для використання після таких команд, як git checkout або git reset. (Див. опцію конфігураційного файлу svn-remote.<name>.automkdirs для отримання додаткової інформації.)

commit-diff

Виконує порівняння двох деревоподібних аргументів з командного рядка. Ця команда не залежить від перебування всередині репозиторію, ініційованого за допомогою git svn init. Ця команда приймає три аргументи: (a) оригінальне дерево для порівняння, (b) результат нового дерева, (c) URL-адресу цільового репозиторію Subversion. Останній аргумент (URL) можна пропустити, якщо ви працюєте з репозиторію, що підтримує git svn' (який був `init-ований за допомогою ‘git svn’). Для цього потрібна опція -r<revision>.

Повідомлення про коміт надсилається або безпосередньо з опцією -m або -F, або опосередковано з тегу чи коміту, коли друге деревоподібне значення позначає такий обʼєкт, або запитується викликом редактора (див. опцію --edit нижче).

-m <msg>
--message=<msg>

Використовувати задане msg як повідомлення коміту. Ця опція вимикає опцію --edit.

-F <filename>
--file=<filename>

Взяти повідомлення коміту з заданого файлу. Ця опція вимикає опцію --edit.

info

Показує інформацію про файл або теку, подібну до того, що надає ‘svn info’. Наразі не підтримує аргумент -r/--revision. Використовуйте опцію --url, щоб вивести лише значення поля URL:.

proplist

Показує перелік властивостей, що зберігаються в репозиторії Subversion, щодо вказаного файлу або теки. Використовуйте -r/--revision для посилання на певну ревізію Subversion.

propget

Отримує властивість Subversion, задану як перший аргумент, для файлу. Конкретну ревізію можна вказати за допомогою -r/--revision.

propset

Встановлює властивість Subversion, задану як перший аргумент, на значення, задане як другий аргумент, для файлу, заданого як третій аргумент.

Приклад:

git svn propset svn:keywords "FreeBSD=%H" devel/py-tipper/Makefile

Це встановить властивість svn:keywords на FreeBSD=%H для файлу devel/py-tipper/Makefile.

show-externals

Показує зовнішні елементи Subversion. Використовуйте -r/--revision, щоб вказати конкретну ревізію.

gc

Стиснути файли $GIT_DIR/svn/<refname>/unhandled.log та видалити файли $GIT_DIR/svn/<refname>/index.

reset

Скасовує ефекти команди fetch назад до вказаної ревізії. Це дозволяє повторно «отримати» ревізію SVN. Зазвичай вміст ревізії SVN ніколи не повинен змінюватися, і reset не потрібен. Однак, якщо змінилися дозволи SVN або ви змінили параметр --ignore-paths, fetch може завершитися невдачею з повідомленням «not found in commit» (файл раніше не був видимим) або «checksum mismatch» (пропущена модифікація). Якщо проблемний файл не можна ігнорувати назавжди (за допомогою --ignore-paths), єдиний спосіб відновити репозиторій — це скористатись reset.

Змінюються лише rev_map та refs/remotes/git-svn (докладніше див. $GIT_DIR/svn/**/.rev_map.* у розділі ФАЙЛИ нижче). Після reset виконайте fetch, а потім git reset або git rebase, щоб перемістити локальні гілки на нове дерево.

-r <n>
--revision=<n>

Вкажіть найновішу ревізію, яку потрібно зберегти. Усі пізніші ревізії буде відкинуто.

-p
--parent

Також відкинути зазначену ревізію, залишивши найближчу батьківську.

Приклад:

Припустимо, у вас є локальні зміни в "master", але вам потрібно повторно завантажити "r2".

    r1---r2---r3 remotes/git-svn
                \
                 A---B master

Виправте проблему з ігноруванням шляхів або правами доступу SVN, яка призвела до неповного виконання "r2". Потім:

git svn reset -r2 -p
git svn fetch
    r1---r2'--r3' remotes/git-svn
      \
       r2---r3---A---B master

Потім виправте "master" за допомогою git rebase. НЕ використовуйте git merge, інакше ваша історія не буде сумісною з майбутнім dcommit!

git rebase --onto remotes/git-svn A^ master
    r1---r2'--r3' remotes/git-svn
                \
                 A'--B' master

ОПЦІЇ

--shared[=(false|true|umask|group|all|world|everybody)]
--template=<template-directory>

Використовується лише з командою init. Вони передаються безпосередньо до git init.

-r <arg>
--revision <arg>

Використовується з командою fetch.

Це дозволяє підтримувати діапазони ревізій для часткової/урізаної історії. Підтримуються $NUMBER, $NUMBER1:$NUMBER2 (числові діапазони), $NUMBER:HEAD та BASE:$NUMBER.

Це може дозволити вам створювати часткові дзеркала під час запуску fetch; але загалом не рекомендується, оскільки історія буде пропущена та втрачена.

-
--stdin

Використовується лише з командою set-tree.

Зчитує список комітів зі stdin та фіксує їх у зворотному порядку. З кожного рядка зчитується лише початковий sha1, тому можна використовувати вивід git rev-list --pretty=oneline.

--rmdir

Використовується лише з командами dcommit, set-tree та commit-diff.

Видаляє теки з дерева SVN, якщо в ньому не залишилося файлів. SVN може контролювати версії порожніх тек, і вони не видаляються зазвичай, якщо в них не залишилося файлів. Git не може контролювати версії порожніх тек. Увімкнення цього прапорця призведе до того, що коміт у SVN працюватиме як Git.

config key: svn.rmdir
-e
--edit

Використовується лише з командами dcommit, set-tree та commit-diff.

Відредагуйте повідомлення коміту перед комітом у SVN. Є стандартно вимкненим для обʼєктів, які є комітами, та примусово вмикається під час коміту обʼєктів дерев.

config key: svn.edit
-l<num>
--find-copies-harder

Використовується лише з командами dcommit, set-tree та commit-diff.

Обидва передаються безпосередньо до git diff-tree; див. git-diff-tree[1] для отримання додаткової інформації.

config key: svn.l
config key: svn.findcopiesharder
-A<filename>
--authors-file=<filename>

Синтаксис сумісний з файлом, який використовується командою git cvsimport, але за допомогою <> можна вказати порожню адресу електронної пошти:

	loginname = Joe User <user@example.com>

Якщо цей параметр вказано, і git svn виявляє імʼя комітера SVN, якого немає в файлі authors-file, git svn перерве операцію. Користувачеві доведеться додати відповідний запис. Повторний запуск попередньої команди git svn після зміни файлу authors-file має продовжити операцію.

config key: svn.authorsfile
--authors-prog=<filename>

Якщо вказано цей параметр, для кожного імені комітера SVN, якого немає у файлі авторів, запускається вказана програма, передаючи ім’я комітера як перший аргумент. Програма повинна повернути один рядок у форматі «Ім’я <email>» або «Ім’я <>», який буде оброблено так, ніби він міститься у файлі авторів.

З історичних причин відносний filename спочатку шукається відносно поточної теки для команд init і clone та відносно кореня робочого дерева для команди fetch. Якщо filename не знайдено, його шукають, як і будь-яку іншу команду, у $PATH.

config key: svn.authorsProg
-q
--quiet

Робить вивід git svn менш детальним. Вкажіть другий раз, щоб зробити його ще менш детальним.

-m
--merge
-s<strategy>
--strategy=<strategy>
-p
--rebase-merges

Параметри використовуються лише з командами dcommit та rebase.

Передається безпосередньо до git rebase при використанні dcommit, якщо git reset не може бути використаний (див. dcommit).

-n
--dry-run

Можна використовувати з командами dcommit, rebase, branch та tag.

Для dcommit виведіть послідовність аргументів Git, які показуватимуть, які різниці будуть зафіксовані в SVN.

Для rebase показує локальну гілку, повʼязану з основним репозиторієм svn, повʼязаним з поточною гілкою, та URL-адресу репозиторію svn, з якого буде отримано дані.

Для branch та tag покаже URL-адреси, які будуть використані для копіювання під час створення гілки або тегу.

--use-log-author

Під час отримання svn-комітів у Git (як частина операцій fetch, rebase або dcommit), шукати перший рядок From: або трейлер Signed-off-by у повідомленні журналу та використовуйте його як рядок автора.

config key: svn.useLogAuthor
--add-author-from

Під час фіксації змін у svn із Git (у рамках операцій set-tree або dcommit), якщо наявне повідомлення журналу ще не містить кінцевого рядка From: або Signed-off-by, додавати рядок From: на основі рядка автора коміту Git. Якщо ви скористаєтеся цією функцією, то параметр --use-log-author отримає правильний рядок автора для всіх комітів.

config key: svn.addAuthorFrom

РОЗШИРЕНІ ПАРАМЕТРИ

-i<GIT_SVN_ID>
--id <GIT_SVN_ID>

Це встановлює GIT_SVN_ID (замість використання середовища). Дозволяє користувачеві перевизначити стандартне посилання для отримання даних під час відстеження окремої URL-адреси. Команди log та dcommit більше не потребують цього параметра.

-R<remote-name>
--svn-remote <remote-name>

Вкажіть розділ [svn-remote "<remote-name>"] для використання, це дозволить відстежувати кілька репозиторіїв SVN. Стандартно — "svn"

--follow-parent

Ця опція має значення лише в тому випадку, якщо ми відстежуємо гілки (використовуючи одну з опцій структури репозиторію: --trunk, --tags, --branches, --stdlayout). Для кожної відстежуваної гілки слід спробувати з’ясувати, звідки було скопійовано її ревізію, і встановити відповідний батьківський коміт у першому коміті Git для цієї гілки. Це особливо корисно, коли ми відстежуємо теку, яку було переміщено в межах репозиторію. Якщо ця функція вимкнена, гілки, створені за допомогою git svn, будуть лінійними і не матимуть спільної історії, тобто не буде інформації про те, де гілки відгалужувалися або зливалися. Однак відстеження довгих/заплутаних історій може зайняти багато часу, тому вимкнення цієї функції може пришвидшити процес клонування. Ця функція стандартно ввімкнена, для її вимкнення використовуйте --no-follow-parent.

config key: svn.followparent

ОПЦІЇ КОНФІГУРАЦІЇ FILE-ONLY

svn.noMetadata
svn-remote.<name>.noMetadata

Це дозволяє прибрати рядки git-svn-id: у кінці кожного коміту.

Цей параметр можна використовувати лише для одноразового імпорту, оскільки git svn не зможе отримати дані повторно без метаданих. Крім того, якщо ви втратите файли $GIT_DIR/svn/**/.rev_map.*, git svn не зможе їх відновити.

Команда git svn log також не працюватиме в репозиторіях, що використовують це. Використання цього параметра конфліктує з опцією useSvmProps з (сподіваємося) очевидних причин.

Цей варіант НЕ рекомендується, оскільки він ускладнює пошук старих посилань на номери версій SVN у наявній документації, звітах про помилки та архівах. Якщо ви плануєте зрештою перейти з SVN на Git і впевнені, що потрібно видалити історію SVN, розгляньте git-filter-repo. filter-repo також дозволяє переформатувати метадані для зручності читання та перезаписувати інформацію про авторство для користувачів, які не користуються "svn.authorsFile".

svn.useSvmProps
svn-remote.<name>.useSvmProps

Дозволяє git svn перепризначати URL-адреси репозиторіїв та UUID з дзеркал, створених за допомогою SVN::Mirror (або svk) для метаданих.

Якщо SVN-ревізія має властивість "svm:headrev", ймовірно, що ревізію було створено за допомогою SVN::Mirror (також використовується SVK). Властивість містить UUID репозиторію та ревізію. Ми хочемо створити враження, що ми дзеркалюємо оригінальну URL-адресу, тому додамо допоміжну функцію, яка повертає оригінальну URL-адресу ідентифікатора та UUID, і використовуватиме її під час створення метаданих у повідомленнях комітів.

svn.useSvnsyncProps
svn-remote.<name>.useSvnsyncprops

Подібно до опції useSvmProps; це для користувачів команди svnsync(1), що постачається з SVN 1.4.x та пізніших версій.

svn-remote.<name>.rewriteRoot

Дозволяє користувачам створювати репозиторії з альтернативних URL-адрес. Наприклад, адміністратор може запустити git svn на сервері локально (доступ через file://), але бажає розповсюдити репозиторій із публічною URL-адресою http:// або svn:// у метаданих, щоб користувачі бачили публічну URL-адресу.

svn-remote.<name>.rewriteUUID

Подібно до опції useSvmProps; це для користувачів, яким потрібно перепризначити UUID вручну. Це може бути корисним у ситуаціях, коли оригінальний UUID недоступний через useSvmProps або useSvnsyncProps.

svn-remote.<name>.pushurl

Подібно до remote.<name>.pushurl у Git, цей ключ призначений для використання у випадках, коли url вказує на SVN-репозиторій через транспорт лише для читання, щоб забезпечити альтернативний транспорт для читання/запису. Передбачається, що обидва ключі вказують на один і той самий репозиторій. На відміну від commiturl, pushurl — це базовий шлях. Якщо можна використовувати commiturl або pushurl, commiturl має пріоритет.

svn.brokenSymlinkWorkaround

Вимикає потенційно витратні перевірки для обходу пошкоджених символічних посилань, що реєструються в SVN пошкодженими клієнтами. Встановіть для цього параметра значення "false", якщо ви відстежуєте репозиторій SVN з багатьма порожніми блоб-обʼєктами, які не є символічними посиланнями. Цей параметр можна змінити під час роботи git svn, і він набуде чинності для наступної отриманої ревізії. Якщо не встановлено, git svn вважатиме цей параметр "true".

svn.pathnameencoding

Наказує git svn перекодувати шляхи до заданого кодування. Параметр можуть використовувати користувачі Windows та ті, хто працює з локалізацією, відмінною від utf8, щоб уникнути пошкодження імен файлів символами, що не належать до ASCII. Дійсні кодування — це ті, що підтримуються модулем Encode в Perl.

svn-remote.<name>.automkdirs

Зазвичай команди "git svn clone" та "git svn rebase" намагаються відтворити порожні теки, які знаходяться в репозиторії Subversion. Якщо для цього параметра встановлено значення "false", то порожні теки будуть створені лише за умови явного виконання команди "git svn mkdirs". Якщо значення не встановлено, git svn вважатиме цей параметр значенням "true".

Оскільки опції noMetadata, rewriteRoot, rewriteUUID, useSvnsyncProps та useSvmProps впливають на метадані, що генеруються та використовуються git svn; їх має бути встановлено у файлі конфігурації перед імпортом будь-якої історії, і ці налаштування ніколи не слід змінювати після їх встановлення.

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

ОСНОВНІ ПРИКЛАДИ

Відстеження та внесення змін до основної гілки проєкту, що керується Subversion (без урахування тегів та гілок):

# Clone a repo (like git clone):
	git svn clone http://svn.example.com/project/trunk
# Enter the newly cloned directory:
	cd trunk
# You should be on master branch, double-check with 'git branch'
	git branch
# Do some work and commit locally to Git:
	git commit ...
# Something is committed to SVN, rebase your local changes against the
# latest changes in SVN:
	git svn rebase
# Now commit your changes (that were committed previously using Git) to SVN,
# as well as automatically updating your working HEAD:
	git svn dcommit
# Append svn:ignore and svn:global-ignores settings to the default Git exclude file:
	git svn show-ignore >> .git/info/exclude

Відстеження та участь у роботі над проєктом, що повністю управляється за допомогою Subversion (з основним гілкою, тегами та гілками):

# Clone a repo with standard SVN directory layout (like git clone):
	git svn clone http://svn.example.com/project --stdlayout --prefix svn/
# Or, if the repo uses a non-standard directory layout:
	git svn clone http://svn.example.com/project -T tr -b branch -t tag --prefix svn/
# View all branches and tags you have cloned:
	git branch -r
# Create a new branch in SVN
	git svn branch waldo
# Reset your master to trunk (or any other branch, replacing 'trunk'
# with the appropriate name):
	git reset --hard svn/trunk
# You may only dcommit to one branch/tag/trunk at a time.  The usage
# of dcommit/rebase/show-ignore should be the same as above.

Початкове виконання команди git svn clone може зайняти чимало часу (особливо у випадку великих репозиторіїв Subversion). Якщо кілька користувачів (або один користувач, який має кілька комп’ютерів) хочуть використовувати git svn для роботи з одним і тим самим репозиторієм Subversion, можна спочатку виконати git svn clone для репозиторію на сервері, а потім кожному користувачеві клонувати цей репозиторій за допомогою команди git clone:

# Do the initial import on a server
	ssh server "cd /pub && git svn clone http://svn.example.com/project [options...]"
# Clone locally - make sure the refs/remotes/ space matches the server
	mkdir project
	cd project
	git init
	git remote add origin server:/pub/project
	git config --replace-all remote.origin.fetch '+refs/remotes/*:refs/remotes/*'
	git fetch
# Prevent fetch/pull from remote Git server in the future,
# we only want to use git svn for future updates
	git config --remove-section remote.origin
# Create a local branch from one of the branches just fetched
	git checkout -b master FETCH_HEAD
# Initialize 'git svn' locally (be sure to use the same URL and
# --stdlayout/-T/-b/-t/--prefix options as were used on server)
	git svn init http://svn.example.com/project [options...]
# Pull the latest changes from Subversion
	git svn rebase

REBASE ЧИ PULL/MERGE

Для синхронізації неінтегрованих комітів з гілкою git svn краще використовувати git svn rebase або git rebase, а не git pull або git merge. Це дозволить зберегти історію неінтегрованих комітів лінійною відносно основного репозиторію 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, користувачам SVN. Тому користувачам рекомендується зберігати історію в Git якомога лінійнішою, щоб полегшити сумісність із SVN (див. розділ ЗАСТЕРЕЖЕННЯ нижче).

РОБОТА З ГІЛКАМИ SVN

Якщо git svn налаштовано на вибірку гілок (і активовано --follow-branches), іноді створюється кілька гілок Git для однієї гілки SVN, де додаткові гілки мають назви у вигляді branchname@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: <branchname>”.

Крім того, буде створено спеціальну гілку з назвою <branchname>@<SVN-Revision>, де <SVN-Revision> — це номер ревізії SVN, з якої було скопійовано гілку. Ця гілка вказуватиме на щойно створений батьківський коміт гілки. Якщо в SVN гілку було видалено, а згодом відтворено з іншої версії, таких гілок із символом @ буде декілька.

Зверніть увагу, що це може означати, що для однієї ревізії SVN створюється кілька комітів Git.

Приклад: у SVN-репозиторії зі стандартною структурою trunk/tags/branches у версії r.100 створюється тека trunk/sub. У версії 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 клонували, збирали та надсилали код безпосередньо з SVN-сервера, та уникали всіх операцій git clone/pull/merge/push між репозиторіями та гілками Git. Рекомендований метод обміну кодом між гілками Git та користувачами — git format-patch та git am, або просто dcommit до SVN-репозиторію.

Виконання git merge або git pull НЕ рекомендується в гілці, з якої ви плануєте зробити dcommit, оскільки користувачі Subversion не можуть бачити жодних злиттів, які ви зробили. Крім того, якщо ви виконуєте злиття або витягування з гілки Git, яка є дзеркалом гілки SVN, dcommit може внести зіміни до неправильної гілки.

Якщо ви виконуєте злиття, зверніть увагу на таке правило: git svn dcommit спробує створити коміт поверх SVN-коміту, зазначеного в

git log --grep=^git-svn-id: --first-parent -1

Тому ви повинні переконатися, що найновіший коміт гілки, до якої ви хочете зробити dcommit, є першим батьківським комітом злиття. Інакше виникне хаос, особливо якщо перший батьківський коміт є старішим комітом у тій самій гілці SVN.

git clone не клонує гілки в ієрархії refs/remotes/ або будь-яких метаданих git svn чи конфігурації. Тому репозиторії, створені та керовані за допомогою git svn, повинні використовувати rsync для клонування, якщо клонування взагалі має бути виконане.

Оскільки команда dcommit під капотом використовує rebase, будь-які гілки Git, які ви передаєте за допомогою git push перш ніж виконати dcommit, вимагатимуть примусового перезапису наявного ref у віддаленому репозиторії. Це, як правило, вважається поганою практикою; детальніше див. документацію за посиланням git-push[1].

Не використовуйте опцію --amend команди git-commit[1] для змін, які ви вже зафіксували (dcommit) у SVN. Вважається поганою практикою коригувати (--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, щоб гілки та теги були повʼязані з різними просторами імен. Наприклад:

branches = stable/*:refs/remotes/svn/stable/*
branches = debug/*:refs/remotes/svn/debug/*

КОНФІГУРАЦІЯ

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

[svn-remote "project-a"]
	url = http://server.org/svn
	fetch = trunk/project-a:refs/remotes/project-a/trunk
	branches = branches/*/project-a:refs/remotes/project-a/branches/*
	branches = branches/release_*:refs/remotes/project-a/branches/release_*
	branches = branches/re*se:refs/remotes/project-a/branches/*
	tags = tags/*/project-a:refs/remotes/project-a/tags/*

Майте на увазі, що символ-замінник * (зірочка) у локальному посиланні (праворуч від :) обовʼязково має бути найправішим компонентом шляху; водночас віддалений символ-замінник може розташовуватися будь-де, за умови, що він є самостійним компонентом шляху (оточеним символами / або кінцем рядка). Такий тип конфігурації не створюється автоматично командою init і його слід ввести вручну за допомогою текстового редактора або за допомогою команди git config.

Також зверніть увагу, що на одне слово дозволено використовувати лише одну зірочку. Наприклад:

branches = branches/re*se:refs/remotes/project-a/branches/*

відповідатиме гілкам release, rese, re123se, однак

branches = branches/re*s*e:refs/remotes/project-a/branches/*

видасть помилку.

Також можна отримати підмножину гілок або тегів, використовуючи список імен, розділених комами, у дужках. Наприклад:

[svn-remote "huge-project"]
	url = http://server.org/svn
	fetch = trunk/src:refs/remotes/trunk
	branches = branches/{red,green}/src:refs/remotes/project-a/branches/*
	tags = tags/{1.0,2.0}/src:refs/remotes/project-a/tags/*

Підтримується кілька ключів fetch, branchs та tags:

[svn-remote "messy-repo"]
	url = http://server.org/svn
	fetch = trunk/project-a:refs/remotes/project-a/trunk
	fetch = branches/demos/june-project-a-demo:refs/remotes/project-a/demos/june-demo
	branches = branches/server/*:refs/remotes/project-a/branches/*
	branches = branches/demos/2011/*:refs/remotes/project-a/2011-demos/*
	tags = tags/server/*:refs/remotes/project-a/tags/*

Створення гілки в такій конфігурації вимагає визначення неоднозначності розташування за допомогою прапорця -d або --destination:

$ git svn branch -d branches/server release-2-3-0

Зверніть увагу, що git-svn відстежує найвищу ревізію, в якій зʼявилася гілка або тег. Якщо підмножина гілок або тегів змінюється після отримання, тоді $GIT_DIR/svn/.metadata необхідно вручну відредагувати, щоб видалити (або скинути) branches-maxRev та/або tags-maxRev відповідно.

ФАЙЛИ

$GIT_DIR/svn/**/.rev_map.*

Зіставлення між номерами версій Subversion та іменами комітів Git. У репозиторії, де не встановлено опцію noMetadata, це можна перебудувати з рядків git-svn-id:, які знаходяться в кінці кожного коміту (див. розділ svn.noMetadata вище для отримання детальнішої інформації).

Команди git svn fetch та git svn rebase автоматично оновлюють rev_map, якщо він відсутній або неактуальний. Команда git svn reset автоматично перемотує його назад.

ПОМИЛКИ

Ми ігноруємо всі властивості SVN, окрім svn:executable. Будь-які необроблені властивості записуються в $GIT_DIR/svn/<refname>/unhandled.log

Перейменовані та скопійовані теки не виявляються Git і, отже, не відстежуються під час коміту в SVN. Я не планую додавати підтримку для цього, оскільки це досить складно та займає багато часу, щоб налаштувати роботу для всіх можливих критичних випадків (Git також цього не робить). Коміт перейменованих та скопійованих файлів повністю підтримується, якщо вони достатньо схожі, щоб Git міг їх виявити.

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

ДИВ. ТАКОЖ

git-rebase[1]

GIT

Частина набору git[1]