git-svn - Інтернет у хмарі

ПРОГРАМА:

ІМ'Я

git-svn - двонаправлена ​​операція між репозиторієм Subversion і Git

СИНТАКСИС

мерзотник svn [варіанти] [аргументи]

ОПИС

мерзотник svn є простим каналом для наборів змін між Subversion і Git. Він забезпечує а
двонаправлений потік змін між Subversion і репозиторієм Git.

мерзотник svn може відстежувати стандартний репозиторій Subversion, дотримуючись загального
макет "стовбур/гілки/теги" з опцією --stdlayout. Він також може слідувати за гілками та
теги в будь-якому макеті з параметрами -T/-t/-b (див. параметри для ініціалізації нижче, а також
клон команда)

Після відстеження репозиторію Subversion (за допомогою будь-якого з перерахованих вище методів) сховище Git
можна оновити з Subversion за допомогою отримувати команду та Subversion, оновлені з Git за допомогою
dcommit команда

КОМАНДИ

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

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

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

--use-svm-props
Встановіть використовуватиSvmProps параметр у конфігурації [svn-remote].

--use-svnsync-props
Встановіть використовуватиSvnsyncProps параметр у конфігурації [svn-remote].

--rewrite-root=
Встановіть rewriteRoot параметр у конфігурації [svn-remote].

--rewrite-uuid=
Встановіть переписатиUUID параметр у конфігурації [svn-remote].

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

--префікс=
Це дозволяє вказати префікс, який ставиться перед іменами пультів if
вказано стовбур/гілки/теги. Префікс автоматично не включає a
кінцеву косу риску, тому переконайтеся, що ви включили її в аргумент, якщо ви це так
хочу. Якщо вказано --branches/-b, префікс повинен містити кінцеву косу риску.
Встановлення префікса (із косою рискою) настійно рекомендується в будь-якому випадку, як
тоді ваші посилання для відстеження SVN будуть розташовані за адресою "refs/remotes/$prefix/", який is
сумісний з Git's власний дистанційне відстеження посилання розташування (refs/remotes/$remote/).
Встановлення префікса також корисно, якщо ви хочете відстежувати декілька проектів, які спільно використовують
загальне сховище. За замовчуванням для префікса встановлено значення походження /.

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

--ignore-paths=
Коли перейшов до ініціалізації or клон цей регулярний вираз буде збережено як конфігурацію
ключ. Побачити отримувати для опису --ignore-paths.

--include-paths=
Коли перейшов до ініціалізації or клон цей регулярний вираз буде збережено як конфігурацію
ключ. Побачити отримувати для опису --include-paths.

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

отримувати
Отримати невибрані версії з пульта Subversion, який ми відстежуємо. Ім'я
Розділ [svn-remote "..."] у файлі $GIT_DIR/config можна вказати як необов'язковий
аргумент командного рядка.

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

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

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

--батька
Отримати лише від батьківського SVN поточного HEAD.

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

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

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

Приклади:

Пропускати каталог "doc*" для кожної вибірки

--ignore-paths="^doc"

Пропускати «гілки» та «теги» каталогів першого рівня

--ignore-paths="^[^/]+/(?:branches|tags)"

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

ключ конфігурації: svn-remote. .include-paths

--log-window-size=
Забрати записи журналу на запит під час сканування історії Subversion. За замовчуванням є
100. Для дуже великих репозиторіїв Subversion можуть знадобитися більші значення для
клон/отримувати завершити в розумні терміни. Але занадто великі значення можуть призвести до
більше використання пам'яті та тайм-аути запитів.

клон
Runs ініціалізації та отримувати. Він автоматично створить каталог на основі базового імені
URL-адреса, передана йому; або якщо передається другий аргумент; це створить каталог
і працювати в рамках цього. Він приймає всі аргументи, які ініціалізації та отримувати Команди
прийняти; за винятком --принести все та --батька. Після клонування сховища,
отримувати команда зможе оновлювати редакції, не впливаючи на робоче дерево;
і ребаза команда зможе оновити робоче дерево останньою
зміни.

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

--placeholder-filename=
Встановіть назви файлів-заповнювачів, створених за допомогою --preserve-empty-dirs. За замовчуванням:
".gitignore"

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

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

Це приймає всі варіанти, які мерзотник svn отримувати та мерзотник ребаза прийняти. однак,
--принести все отримує лише з поточного [svn-remote], а не з усіх [svn-remote]
визначення.

Люблю мерзотник ребаза; це вимагає, щоб робоче дерево було чистим і не мало незакріплених
зміни.

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

-l, --місцевий
Не отримувати віддалено; тільки бігати мерзотник ребаза проти останнього отриманого коміту з
верхній SVN.

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

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

Використання dcommit є кращим набір дерево (нижче).

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

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

ключ конфігурації: svn-remote. .commiturl
ключ конфігурації: svn.commiturl (перезаписує всі svn-remote. параметри .commiturl)

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

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

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

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

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

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

мерзотник svn dcommit повертається негайно, якщо відповідь «ні» або «кинути», без
передавання будь-чого до SVN.

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

-m, --повідомлення
Дозволяє вказати повідомлення фіксації.

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

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

git config --get-all svn-remote. .гілки
git config --get-all svn-remote. .теги

де - це ім'я сховища SVN, як зазначено параметром -R до
ініціалізації (або "svn" за замовчуванням).

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

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

git config --get-all svn-remote. .commiturl

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

тег
Створіть тег у сховищі SVN. Це скорочення для філія -t.

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

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

-r [: ], --revision= [: ]
підтримується, нечислові аргументи не є: HEAD, NEXT, BASE, PREV тощо ...

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

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

--інкрементальний
підтриманий

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

--show-commit
також показує фіксацію Git sha1

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

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

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

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

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

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

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

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

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

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

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

commit-diff
Фіксує різницю двох аргументів дерева з командного рядка. Ця команда робить
не покладатися на те, що знаходиться всередині репозиторію git svn init-ed. Ця команда займає три
аргументи, (a) вихідне дерево, з яким потрібно розрізнити, (b) результат нового дерева, (c) URL
цільового репозиторію Subversion. Останній аргумент (URL) може бути опущений, якщо ви
працюють від а мерзотник svn-aware репозиторій (який був ініційований за допомогою мерзотник svn).
-r для цього необхідна опція.

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

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

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

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

gc
Стиснути $GIT_DIR/svn/ /unhandled.log файли та видаліть
$GIT_DIR/svn/ /index файли.

скидання
Скасує наслідки отримувати повернутися до вказаної редакції. Це дозволяє вам
повторноотримувати ревізію SVN. Зазвичай вміст версії SVN ніколи не повинен змінюватися
та скидання не повинно бути необхідним. Однак, якщо дозволи SVN зміняться, або якщо ви зміните
ваш параметр --ignore-paths, a отримувати може завершитися помилкою з "не знайдено в коміті" (файл не
раніше видно) або «невідповідність контрольної суми» (пропущена модифікація). Якщо проблема
файл не можна ігнорувати назавжди (з --ignore-paths) єдиний спосіб відновити репо
полягає у використанні скидання.

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

-r , --revision=
Укажіть останню редакцію для збереження. Усі подальші редакції відхиляються.

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

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

r1---r2---r3 пульти/git-svn

А---В майстер

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

git svn reset -r2 -p
git svn вибірка

r1---r2'--r3' пульти/git-svn

r2---r3---A---B майстер

Потім закріплюємо «майстром» с мерзотник ребаза. Не використовувати мерзотник злиття або ваша історія не буде
бути сумісним із майбутнім dcommit!

git rebase --onto remotes/git-svn A^ master

r1---r2'--r3' пульти/git-svn

А'--В' майстер

ВАРІАНТИ

--shared[=(false|true|umask|group|all|world|everybody)], --template=
Використовується тільки з ініціалізації команда. Вони передаються безпосередньо до мерзотник ініціалізації.

-r , --перегляд
Використовується з отримувати команда

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

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

-, --stdin
Використовується тільки з набір дерево команда

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

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

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

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

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

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

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

-л , --знайти-копії-складніше
Використовується тільки з dcommit, набір дерево та commit-diff команди.

Вони обидва передаються безпосередньо до мерзотник diff-дерево; подивитися git-різниця-дерево(1) більше
інформація.

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

-А , --authors-file=
Синтаксис сумісний з файлом, який використовується мерзотник cvsimport:

Ім'я користувача = Joe Useruser@example.com>

Якщо цей параметр вказано і мерзотник svn зустрічає ім'я комітера SVN, яке не має
існують у файлі авторів, мерзотник svn перерве операцію. Тоді користувачеві доведеться
додати відповідний запис. Повторне виконання попереднього мерзотник svn команда після
Authors-файл змінено, слід продовжити роботу.

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

--authors-prog=
Якщо вказано цю опцію, для кожного імені комітера SVN, яке не існує в файлі
Authors, цей файл виконується з ім'ям комітера як першим
аргумент. Очікується, що програма поверне один рядок виду «Ім’я ",
які розглядатимуться як включені до файлу авторів.

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

-м, --злиття, -с , --стратегія= , -p, --зберегти-злиття
Вони використовуються лише з dcommit та ребаза команди.

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

-n, --сухий біг
Це можна використовувати з dcommit, ребаза, філія та тег команди.

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

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

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

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

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

ADVANCED ВАРІАНТИ

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

-Р , --svn-remote
Вкажіть [svn-remote " "] для використання, це дозволяє використовувати декілька SVN
сховища, які слід відстежувати. За замовчуванням: "svn"

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

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

КОНФІГ ТІЛЬКИ ФАЙЛ ВАРІАНТИ

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

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

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

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

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

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

svn.useSvnsyncProps, svn-remote. .useSvnsyncprops
Подібно до параметра useSvmProps; це для користувачів svnsync(1) команда
розповсюджується разом із SVN 1.4.x та пізнішими.

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

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

svn-віддалений. .pushurl
Схожий на Git дистанційний. .pushurl, цей ключ призначений для використання в тих випадках, коли
URL вказує на репозиторій SVN за допомогою транспорту лише для читання, щоб надати альтернативу
читання/запис транспорту. Передбачається, що обидва ключі вказують на одне і те ж сховище.
на відміну від commiturl, pushurl є базовим шляхом. Якщо будь-який commiturl or pushurl може бути
б / в, commiturl має пріоритет.

svn.brokenSymlinkОбхідне рішення
Це вимикає потенційно дорогі перевірки, щоб обійти зареєстровані зламані символічні посилання
SVN від зламаних клієнтів. Установіть для цього параметра значення "false", якщо ви відстежуєте репозиторій SVN за допомогою
багато порожніх крапель, які не є символічними посиланнями. Цей параметр може бути змінений поки мерзотник svn is
запущено та набуде чинності після отримання наступної версії. Якщо не встановлено, мерзотник svn припускає це
варіант бути «правдивим».

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

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

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

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

BASIC ПРИКЛАДИ

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

# Клонуйте репо (наприклад, git clone):
клон git svn http://svn.example.com/project/trunk
# Введіть щойно клонований каталог:
багажник компакт-дисків
# Ви повинні бути на головній гілці, двічі перевірте за допомогою 'git branch'
гілка git
# Виконайте деяку роботу та закріпіть локально Git:
git фіксувати ...
# Щось прихильно до SVN, перебазуйте ваші локальні зміни відповідно до
# останні зміни в SVN:
git svn rebase
# Тепер зафіксуйте свої зміни (які були внесені раніше за допомогою Git) у SVN,
#, а також автоматичне оновлення робочого HEAD:
git svn dcommit
# Додати параметри svn:ignore до файлу виключення Git за замовчуванням:
git svn show-ignore >> .git/info/exclude

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

# Клонуйте репо зі стандартним макетом каталогу SVN (наприклад, git clone):
клон git svn http://svn.example.com/project --stdlayout --префікс svn/
# Або, якщо репозиторій використовує нестандартний макет каталогу:
клон git svn http://svn.example.com/project -T tr -b гілка -t тег --префікс svn/
# Переглянути всі гілки та теги, які ви клонували:
git гілка -r
# Створіть нову гілку в SVN
git svn гілка waldo
# Скиньте головну частину до магістралі (або будь-якої іншої гілки, замінивши "магістр")
# з відповідною назвою):
git reset --hard svn/trunk
# Ви можете закріпити лише одну гілку/тег/ствол одночасно. Використання
Кількість dcommit/rebase/show-ignore має бути таким же, як і вище.

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

# Виконайте початковий імпорт на сервері
ssh-сервер "cd /pub && git svn clone http://svn.example.com/project [параметри...]"
# Клонувати локально - переконайтеся, що простір refs/remotes/ відповідає серверу
проект mkdir
CD проект
git init
git віддалений додавання вихідного сервера:/pub/project
git config --replace-all remote.origin.fetch '+refs/remotes/*:refs/remotes/*'
git fetch
# Заборонити отримання/витягування з віддаленого сервера Git в майбутньому,
# ми хочемо використовувати git svn лише для майбутніх оновлень
git config --remove-section remote.origin
# Створіть локальну гілку з однієї з щойно отриманих гілок
git checkout -b головний FETCH_HEAD
# Ініціалізуйте 'git svn' локально (обов'язково використовуйте ту саму URL-адресу і
# --stdlayout/-T/-b/-t/--параметри префікса, які використовувалися на сервері)
git svn init http://svn.example.com/project [варіанти...]
# Витягніть останні зміни з Subversion
git svn rebase

ПЕРЕБАЗУВАТИ VS. ВЯГТИ/ЗЛИТИ

Віддають перевагу використанню мерзотник svn ребаза or мерзотник ребаза, А чи не мерзотник тягнути or мерзотник злиття до
синхронізувати неінтегровані коміти з a мерзотник svn відділення. Це дозволить зберегти історію
неінтегровані фіксують лінійні по відношенню до попереднього репозиторію SVN і дозволяють використовувати
з бажаних мерзотник svn dcommit підкоманда для переміщення неінтегрованих комітів назад у SVN.

Спочатку мерзотник svn рекомендував розробникам витягнути або об'єднати з мерзотник svn філія
Це сталося тому, що автор віддав перевагу git svn set-tree B для фіксації однієї голови, а не
нотація git svn set-tree A..B для фіксації кількох комітів. Використання мерзотник тягнути or мерзотник
злиття з git svn set-tree A..B призведе до вирівнювання нелінійної історії, коли
фіксації в SVN, і це може призвести до злиття фіксацій, неочікувано відмінюючи попередні
фіксує в SVN.

ВЕЛИКИЙ ПЕРЕШКОДИ

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

HANDLING OF SVN ФІЛІЇ

If мерзотник svn налаштовано на отримання гілок (і діє --follow-branches), це
іноді створює кілька гілок Git для однієї гілки SVN, де додаткові гілки
мають назви форми ім'я філії@nnn (з nnn номером версії SVN). Ці додаткові
гілки створюються, якщо мерзотник svn не може знайти батьківський коміт для першого коміту в SVN
відділення, щоб зв'язати філію з історією інших філій.

Зазвичай перший коміт у гілці SVN складається з операції копіювання. мерзотник svn волі
прочитайте цю фіксацію, щоб отримати версію SVN, з якої була створена гілка. Тоді воно буде намагатися
знайдіть коміт Git, який відповідає цій версії SVN, і використовуйте його як батьківський
відділення. Однак можливо, що немає відповідного коміту Git, яким би служив
батьківський. Це станеться, серед інших причин, якщо гілка SVN є копією ревізії
що не було отримано мерзотник svn (наприклад, тому що це стара редакція, яку було пропущено
--перегляд), або якщо в SVN був скопійований каталог, який не відстежується мерзотник svn (наприклад, a
гілка, яка взагалі не відстежується, або підкаталог відстежуваної гілки). У цих випадках
мерзотник svn все одно створить гілку Git, але замість того, щоб використовувати наявний коміт Git як
батьківський елемент гілки, він прочитає історію SVN каталогу, скопійовану гілки
з і створіть відповідні коміти Git. Про це свідчить повідомлення «Ініціалізація
батько: ".

Крім того, він створить спеціальну гілку з ім’ям @, Де
це номер версії SVN, з якої скопійовано гілку. Ця філія буде
вказати на щойно створений батьківський коміт гілки. Якщо в SVN гілка була видалена
і пізніше відтворених з іншої версії, буде кілька таких гілок з
@.

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

Приклад: у сховищі SVN зі стандартним макетом магістралей/тегів/гілок, каталог
trunk/sub створено в r.100. У r.200 trunk/sub розгалужується шляхом копіювання його в branches/.
мерзотник svn клон -s потім створить гілку нижче. Він також створить нові коміти Git для
r.100 – r.199 і використовувати їх як історію галузі нижче. Таким чином, буде два Git
фіксує для кожної редакції від r.100 до r.199 (один містить trunk/, один містить
магістраль/підряд/). Нарешті, це створить гілку нижче @ 200 вказуючи на новий батьківський коміт
філія нижче (тобто фіксація для r.200 і trunk/sub/).

ПЕРЕКЛАДИ

Заради простоти та взаємодії з Subversion, рекомендується зробити все
мерзотник svn користувачі клонують, завантажують і фіксують безпосередньо з сервера SVN і уникають усього мерзотник
клон/тягнути/злиття/штовхати операції між сховищами Git і гілками. Рекомендований
методом обміну кодом між гілками Git і користувачами є мерзотник формат-патч та мерзотник am,
або просто 'dcommit' до сховища SVN.

Робота мерзотник злиття or мерзотник тягнути НЕ рекомендується у філії, яку ви плануєте dcommit від
оскільки користувачі Subversion не можуть бачити жодного злиття, яке ви зробили. Крім того, якщо ви об’єднаєте або
витягнути з гілки Git, яка є дзеркалом гілки SVN, dcommit може вчинити неправильно
філія

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

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

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

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

З dcommit використовує rebase всередині, будь-який Git розгалужує вас мерзотник штовхати до раніше dcommit on
вимагатиме примусового перезапису існуючого ref у віддаленому сховищі. Це
зазвичай вважається поганою практикою, див git-push(1) документація для деталей.

Не використовуйте параметр --amend git-commit(1) щодо зміни, яку ви вже внесли. Це
вважається поганою практикою для --amend фіксацій, які ви вже перемістили до віддаленого сховища
для інших користувачів, і dcommit з SVN аналогічний цьому.

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

При використанні кількох --branch або --тегів, мерзотник svn не обробляє автоматично ім'я
колізії (наприклад, якщо дві гілки з різних шляхів мають однакову назву, або якщо a
гілка і тег мають однакову назву). У цих випадках використовуйте ініціалізації щоб налаштувати свій Git
сховище тоді, перед вашим першим отримувати, відредагуйте файл $GIT_DIR/config так, щоб
гілки та теги пов'язані з різними просторами імен. Наприклад:

гілки = стабільний/*:refs/remotes/svn/stable/*
гілки = debug/*:refs/remotes/svn/debug/*

Використовуйте git-svn онлайн за допомогою служб onworks.net