українська мова ▾ Topics ▾ Latest version ▾ git-svn last updated in 2.47.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=<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).*$, можна використовувати, щоб дозволити лише певні посилання.

ключ конфігурації: svn-remote.<name>.ignore-refs

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

--ignore-paths=<regex>

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

ключ конфігурації: 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.

ключ конфігурації: svn-remote.<name>.include-paths
--log-window-size=<n>

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

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

Закомітьте кожну зміну (diff) з поточної гілки безпосередньо до репозиторію SVN, а потім перебазуйте або скиньте (залежно від того, чи є зміна (diff) між SVN та head). Це створить ревізію в SVN для кожного коміту в Git.

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

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

--no-rebase

Після фіксації не перебазуйте та не скидайте налаштування.

--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.<назва>.pushurl.

Використання цієї опції для будь-яких інших цілей (не запитуйте) дуже не рекомендується.

--mergeinfo=<mergeinfo>

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

ключ конфігурації: svn.pushmergeinfo

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

--interactive

Попросіть користувача підтвердити, що набір патчів дійсно має бути надісланий до SVN. Для кожного патча можна відповісти «так» (прийняти цей патч), «ні» (відхилити цей патч), «всі» (прийняти всі патчі) або «вийти».

git svn dcommit повертає негайно, якщо відповідь "ні" або "вийти", без жодних коммітів до SVN.

branch

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

-m
--message

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

-t
--tag

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

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

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

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

де <назва> — це назва 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<версія>.

Повідомлення про коміт надсилається або безпосередньо з опцією -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=<каталог-шаблонів>

Використовується лише з командою 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.

ключ конфігурації: svn.rmdir
-e
--edit

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

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

ключ конфігурації: 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 має продовжити операцію.

ключ конфігурації: svn.authorsfile
--authors-prog=<filename>

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

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

ключ конфігурації: 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, з якого буде отримано дані.

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

--use-log-author

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

ключ конфігурації: svn.useLogAuthor
--add-author-from

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

ключ конфігурації: svn.addAuthorFrom

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

-i<GIT_SVN_ID>
--id <GIT_SVN_ID>

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

-R<віддалене ім’я>
--svn-remote <remote-name>

Вкажіть розділ [svn-remote "<ім’я віддаленого_провайдера>"] для використання, це дозволить відстежувати кілька репозиторіїв SVN. За замовчуванням: "svn"

--follow-parent

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

ключ конфігурації: svn.followparent

ОПЦІЇ ТІЛЬКИ ФАЙЛУ КОНФІГУРАЦІЇ

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» може зайняти досить багато часу (особливо для великих репозиторіїв Subversion). Якщо кілька людей (або одна людина з кількома машинами) хочуть використовувати «git svn» для взаємодії з одним і тим самим репозиторієм Subversion, ви можете виконати початковий «клон git svn» до репозиторію на сервері та попросити кожну людину клонувати цей репозиторій за допомогою «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

ПЕРЕБАЗУВАННЯ ПРОТИ ВИТЯГНЕННЯ/ОБ’ЄДНАННЯ

Для синхронізації неінтегрованих комітів з гілкою git svn краще використовувати git svn rebase або git rebase, а не git pull або git merge. Це дозволить зберегти історію неінтегрованих комітів лінійною відносно основного репозиторію SVN та дозволить використовувати бажану підкоманду git svn dcommit для повернення неінтегрованих комітів у SVN.

Спочатку «git svn» рекомендував розробникам витягувати або зливати зміни з гілки «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. Про це вказує повідомлення "Ініціалізація батьківської гілки: <назвагілки>".

Крім того, буде створено спеціальну гілку з назвою <назва_гілки>@<SVN-Ревізія>, де <SVN-Ревізія> – це номер ревізії 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, вимагатимуть примусового перезапису існуючого посилання на віддаленому репозиторії. Зазвичай це вважається поганою практикою, див. документацію 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, щоб гілки та теги були пов’язані з різними просторами імен. Наприклад:

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

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

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

[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/*

Майте на увазі, що символ підстановки * (зірочка) локального посилання (праворуч від :) повинен бути крайнім правим компонентом шляху; проте віддалений символ підстановки може бути будь-де, якщо він є незалежним компонентом шляху (оточеним / або EOL). Цей тип конфігурації не створюється автоматично командою 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]