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

НАЗВА

git-cvsserver — емулятор CVS-сервера для Git

СИНОПСИС

SSH:

export CVS_SERVER="git cvsserver"
cvs -d :ext:user@server/path/repo.git co <HEAD_name>

pserver (/etc/inetd.conf):

cvspserver потік tcp nowait nobody /usr/bin/git-cvsserver git-cvsserver pserver

Використання:

git-cvsserver [<options>] [pserver|server] [<directory> …​]

ОПИС

Ця програма є шаром емуляції CVS для Git.

Він дуже функціональний. Однак не всі методи реалізовані, а для тих методів, які реалізовані, не всі перемикачі реалізовані.

Тестування проводилося як за допомогою клієнта CLI CVS, так і за допомогою плагіна Eclipse CVS. Більшість функцій добре працюють з обома цими клієнтами.

ОПЦІЇ

Усі ці опції, очевидно, мають сенс лише тоді, коли їх застосовує сервер. Вони були реалізовані якомога точніше схожі на опції git-daemon[1].

--base-path <path>

Додати шлях до запитуваного CVSROOT

--strict-paths

Не дозволяти рекурсію в підкаталоги

--export-all

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

-V
--version

Інформація про версію для друку та вихід

-h
-H
--help

Роздрукувати інформацію про використання та вийти

<directory>

Решта аргументів надають список каталогів. Якщо не вказано жодного каталога, то дозволено використовувати всі. Репозиторії в цих каталогах все ще потребують параметра конфігурації gitcvs.enabled, якщо не вказано --export-all.

ОБМЕЖЕННЯ

Клієнти CVS не можуть позначати тегами, створювати гілки або виконувати злиття Git.

git-cvsserver зіставляє гілки Git з модулями CVS. Це дуже відрізняється від того, чого очікує більшість користувачів CVS, оскільки в CVS модулі зазвичай представляють один або декілька каталогів.

ВСТАНОВЛЕННЯ

  1. Якщо ви збираєтеся пропонувати доступ до CVS через pserver, додайте рядок у /etc/inetd.conf такого вигляду

       cvspserver потік tcp nowait nobody git-cvsserver pserver

    Примітка: Деякі сервери inetd дозволяють вказувати назву виконуваного файлу незалежно від значення argv[0] (тобто назви, з якою програма припускає виконання). У цьому випадку правильний рядок у /etc/inetd.conf виглядає так

       cvspserver потік tcp nowait nobody /usr/bin/git-cvsserver git-cvsserver pserver

    За замовчуванням pserver надає лише анонімний доступ. Щоб зробити фіксацію змін, вам потрібно буде створити облікові записи pserver, просто додайте параметр gitcvs.authdb у конфігураційний файл репозиторіїв, до яких cvsserver має дозволити запис, наприклад:

       [gitcvs]
	authdb = /etc/cvsserver/passwd

    Формат цих файлів такий: ім’я користувача, за яким слідує зашифрований пароль, наприклад:

       myuser:sqkNi8zPf01HI
   myuser:$1$9K7FzU28$VfF6EoPYCJEYcVQwATgOP/
   myuser:$5$.NqmNH1vwfzGpV8B$znZIcumu1tNLATgV2l6e1/mY8RzhUDHMOaVOeL1cxV3

    Ви можете використовувати функцію htpasswd, яка постачається з Apache, для створення цих файлів, але лише з опцією -d (або -B, якщо ваша система її підтримує).

    Бажано використовувати системну утиліту, яка керує створенням хешу паролів на вашій платформі (наприклад, mkpasswd у Linux, encrypt в OpenBSD або pwhash в NetBSD) та вставляти його у потрібне місце.

    Потім введіть свій пароль за допомогою методу pserver, наприклад:

       cvs -d:pserver:someuser:somepassword@server:/path/repo.git co <HEAD_name>

    Для доступу через SSH не потрібне спеціальне налаштування, окрім наявності інструментів Git у PATH. Якщо у вас є клієнти, які не приймають змінну середовища CVS_SERVER, ви можете перейменувати git-cvsserver на cvs.

    Примітка: Новіші версії CVS (>= 1.12.11) також підтримують безпосереднє вказівку CVS_SERVER у CVSROOT, наприклад

       cvs -d ":ext;CVS_SERVER=git cvsserver:user@server/path/repo.git" co <HEAD_name>

    Це має перевагу в тому, що зміни будуть збережені у ваших файлах CVS/Root, і вам не потрібно турбуватися про те, щоб завжди встановлювати правильну змінну середовища. Користувачам SSH, обмеженим доступом до git-shell, не потрібно перевизначати значення за замовчуванням за допомогою CVS_SERVER (і не повинні цього робити), оскільки git-shell розуміє cvs як git-cvsserver і вдає, що інший кінець краще запускає справжній cvs.

  2. Для кожного репозиторію, до якого ви хочете отримати доступ з CVS, вам потрібно відредагувати конфігурацію в репозиторії та додати наступний розділ.

       [gitcvs]
        enabled=1
        # optional for debugging
	logFile=/path/to/logfile

    Примітка: вам потрібно переконатися, що кожен користувач, який збирається викликати git-cvsserver, має доступ на запис до файлу журналу та бази даних (див. Database Backend). Якщо ви хочете запропонувати доступ на запис через SSH, користувачам, звичайно, також потрібен доступ на запис до самого репозиторію Git.

    Також потрібно переконатися, що кожен репозиторій "голий" (без індексного файлу Git), щоб cvs commit працював. Див. gitcvs-migration[7].

    Усі змінні конфігурації також можна перевизначити для певного методу доступу. Дійсні назви методів: "ext" (для доступу SSH) та "pserver". Наведений нижче приклад конфігурації вимкне доступ до pserver, але все ще дозволить доступ через SSH.

       [gitcvs]
        enabled=0

   [gitcvs "ext"]
        enabled=1

  3. Якщо ви не вказали CVSROOT/CVS_SERVER безпосередньо в команді checkout, автоматично зберігаючи його у файлах CVS/Root, тоді вам потрібно явно встановити їх у вашому середовищі. CVSROOT слід встановити як зазвичай, але каталог повинен вказувати на відповідний репозиторій Git. Як і вище, для SSH-клієнтів, які не обмежені git-shell, CVS_SERVER слід встановити на git-cvsserver.

       export CVSROOT=:ext:user@server:/var/git/project.git
   export CVS_SERVER="git cvsserver"

  4. Для SSH-клієнтів, які будуть робити коміти, переконайтеся, що їхні серверні файли .ssh/environment (або .bashrc тощо, залежно від їхньої конкретної оболонки) експортують відповідні значення для GIT_AUTHOR_NAME, GIT_AUTHOR_EMAIL, GIT_COMMITTER_NAME та GIT_COMMITTER_EMAIL. Для SSH-клієнтів, чия оболонка входу — bash, .bashrc може бути розумною альтернативою.

  5. Тепер клієнти повинні мати змогу отримати доступ до проекту. Використовуйте назву CVS module, щоб вказати, який Git head ви хочете отримати. Це також встановлює назву вашого щойно отриманого каталогу, якщо ви не вкажете інше за допомогою -d <ім'я-каталогу>. Наприклад, це виконає отримання гілки master до каталогу project-master:

       cvs co -d project-master master

БЕКЕНД БАЗИ ДАНИХ

«git-cvsserver» використовує одну базу даних на кожен заголовок Git (тобто модуль CVS) для зберігання інформації про репозиторій, щоб підтримувати узгодженість номерів версій CVS. Базу даних потрібно оновлювати (тобто записувати в неї) після кожного коміту.

Якщо коміт виконується безпосередньо за допомогою git (на відміну від використання git-cvsserver), оновлення має відбутися під час наступного доступу до репозиторію за допомогою git-cvsserver, незалежно від методу доступу та запитуваної операції.

Це означає, що навіть якщо ви пропонуєте лише доступ на читання (наприклад, використовуючи метод pserver), git-cvsserver повинен мати доступ на запис до бази даних, щоб надійно працювати (інакше вам потрібно переконатися, що база даних оновлена щоразу, коли виконується git-cvsserver).

За замовчуванням використовуються бази даних SQLite в каталозі Git під назвою gitcvs.<назва-модуля>.sqlite. Зверніть увагу, що серверна частина SQLite створює тимчасові файли в тому ж каталозі, що й файл бази даних, під час запису, тому може бути недостатньо надати користувачам, які використовують git-cvsserver, доступ на запис до файлу бази даних, не надаючи їм також доступ на запис до каталогу.

Базу даних неможливо надійно регенерувати у послідовній формі після зміни гілки, яку вона відстежує. Приклад: Для об’єднаних гілок git-cvsserver відстежує лише одну гілку розробки, і після git merge інкрементально оновлена база даних може відстежувати іншу гілку, ніж база даних, регенерована з нуля, що призводить до невідповідних номерів версій CVS. git-cvsserver не має можливості дізнатися, яку гілку він би вибрав, якби його було запущено інкрементально перед об’єднанням. Тому, якщо вам потрібно повністю або частково (зі старої резервної копії) регенерувати базу даних, вам слід з підозрою ставитися до вже існуючих пісочниць CVS.

Ви можете налаштувати серверну частину бази даних за допомогою таких змінних конфігурації:

Налаштування серверної частини бази даних

«git-cvsserver» використовує модуль Perl DBI. Будь ласка, також ознайомтеся з його документацією, якщо змінюєте ці змінні, особливо щодо DBI->connect().

gitcvs.dbName

Ім’я бази даних. Точне значення залежить від вибраного драйвера бази даних, для SQLite це ім’я файлу. Підтримується підстановка змінних (див. нижче). Не може містити крапку з комою (;). За замовчуванням: %Ggitcvs.%m.sqlite

gitcvs.dbDriver

Використано драйвер DBI. Ви можете вказати будь-який доступний драйвер для цього тут, але він може не працювати. cvsserver тестується з DBD::SQLite, повідомляється, що працює з DBD::Pg, і повідомляється, що не працює з DBD::mysql. Будь ласка, розглядайте це як експериментальну функцію. Не може містити двокрапки (:). За замовчуванням: SQLite

gitcvs.dbuser

Користувач бази даних. Корисно лише при встановленні dbDriver, оскільки SQLite не має концепції користувачів бази даних. Підтримує підстановку змінних (див. нижче).

gitcvs.dbPass

Пароль бази даних. Корисно лише при встановленні dbDriver, оскільки SQLite не має поняття паролів бази даних.

gitcvs.dbTableNamePrefix

Префікс назви таблиці бази даних. Підтримується підстановка змінних (див. нижче). Будь-які неалфавітні символи будуть замінені символами підкреслення.

Усі змінні також можна встановити для кожного методу доступу, див. вище.

Заміна змінних

У dbDriver та dbUser можна використовувати такі змінні:

%G

Ім’я каталогу Git

%g

Назва каталогу Git, де всі символи, крім буквено-цифрових, . та -, замінюються на _ (це має спростити використання назви каталогу в назві файлу, якщо потрібно)

%m

Назва модуля CVS/головного файлу Git

%a

метод доступу (один з "ext" або "pserver")

%u

Ім’я користувача, який запускає «git-cvsserver». Якщо ім’я не може бути визначено, використовується числовий uid.

НАВКОЛИШНЄ СЕРЕДОВИЩЕ

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

GIT_CVSSERVER_BASE_PATH

Ця змінна замінює аргумент --base-path.

GIT_CVSSERVER_ROOT

Ця змінна вказує на один каталог, замінюючи список аргументів <каталог>.... Репозиторій все ще потребує опції конфігурації gitcvs.enabled, якщо не вказано --export-all.

Коли ці змінні середовища встановлено, відповідні аргументи командного рядка не можуть використовуватися.

НОТАТКИ КЛІЄНТА ECLIPSE CVS

Щоб отримати оформлення замовлення за допомогою клієнта Eclipse CVS:

  1. Виберіть "Створити новий проект → З оформлення замовлення CVS"

  2. Створіть нове розташування. Дивіться примітки нижче, щоб дізнатися, як вибрати правильний протокол.

  3. Перегляньте доступні «модулі». Вам буде надано список заголовків у репозиторії. Ви не зможете переглядати дерево звідти. Тільки заголовки.

  4. Виберіть HEAD, коли буде запитувано, яку гілку/тег перевірити. Зніміть позначку з опції "запустити майстер комітів", щоб уникнути коміту файлу .project.

Примітки щодо протоколу: Якщо ви використовуєте анонімний доступ через pserver, просто виберіть його. Тим, хто використовує SSH-доступ, слід вибрати протокол ext та налаштувати доступ ext на панелі Налаштування→Команда→CVS→ExtConnection. Встановіть CVS_SERVER на "git cvsserver". Зверніть увагу, що підтримка паролів погана при використанні ext, вам обов’язково знадобиться налаштувати SSH-ключі.

Або ж ви можете просто скористатися нестандартним протоколом extssh, який пропонує Eclipse. У такому разі CVS_SERVER ігнорується, і вам доведеться замінити утиліту cvs на сервері на git-cvsserver або змінити ваш .bashrc так, щоб виклик cvs фактично викликав git-cvsserver.

КЛІЄНТИ, ЯКІ ВІДОМО ПРАЦЮЮТЬ

  • CVS 1.12.9 на Debian

  • CVS 1.11.17 на MacOSX (з пакета Fink)

  • Eclipse 3.0, 3.1.2 на MacOSX (див. Нотатки до клієнта Eclipse CVS)

  • TortoiseCVS

ПІДТРИМУВАНІ ОПЕРАЦІЇ

Підтримуються всі операції, необхідні для звичайного використання, включаючи перевірку (checkout), зміну (diff), зміну (status), оновлення (update), журнал (log), додавання (added), видалення (remove), фіксацію (commit).

Більшість аргументів команд CVS, які зчитують теги CVS або номери версій (зазвичай -r), працюють, а також підтримують будь-які git refspec (тег, гілку, ідентифікатор коміту тощо). Однак номери версій CVS для гілок, що не є стандартними, погано емулюються, а журнал cvs взагалі не відображає теги чи гілки. (Номери версій CVS, що не належать до основної гілки, зовні нагадують номери версій CVS, але насправді вони безпосередньо кодують ідентифікатор коміту git, а не представляють кількість версій з моменту точки розгалуження.)

Зверніть увагу, що існує два способи отримання певної гілки. Як описано в іншому місці на цій сторінці, параметр "module" функції cvs checkout інтерпретується як назва гілки, і вона стає головною гілкою. Вона залишається головною гілкою для заданої пісочниці, навіть якщо ви тимчасово зробите іншу гілку "липкою" за допомогою cvs update -r. Як варіант, аргумент -r може вказувати на якусь іншу гілку для фактичного отримання, навіть якщо модуль все ще є "головною" гілкою. Компроміси (як реалізовано наразі): Кожен новий "module" створює нову базу даних на диску з історією для заданого модуля, і після створення бази даних операції з цією головною гілкою виконуються швидко. Або ж -r не займає додаткового місця на диску, але може бути значно повільнішим для багатьох операцій, таких як cvs update.

Якщо ви хочете звернутися до git refspec, яка містить символи, заборонені CVS, у вас є два варіанти. По-перше, може спрацювати надсилання git refspec безпосередньо до відповідного аргументу CVS -r; деякі клієнти CVS, здається, не виконують перевірку аргументу на правильність. По-друге, якщо це не спрацює, ви можете використовувати спеціальний механізм екранування символів, який використовує лише символи, допустимі в тегах CVS. Послідовність із 4 або 5 символів у форматі (підкреслення ("_"), тире ("-"), один або два символи та тире ("-")) може кодувати різні символи на основі однієї або двох літер: "s" для скісну риску ("/"), "p" для крапки ("."), "u" для підкреслення ("_") або дві шістнадцяткові цифри для будь-якого байтового значення (зазвичай число ASCII або, можливо, частина символу, закодованого UTF-8).

Застарілі операції моніторингу не підтримуються (редагування, перегляд та пов’язані з ним операції). Експорт та позначення тегами (теги та гілки) на цьому етапі не підтримуються.

Перетворення закінчення рядка CRLF

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

Ви можете змусити сервер використовувати атрибути перетворення кінця рядка для встановлення режимів -k для файлів, встановивши змінну конфігурації gitcvs.usecrlfattr. Див. gitattributes[5] для отримання додаткової інформації про перетворення кінця рядка.

Або ж, якщо конфігурація gitcvs.usecrlfattr не ввімкнена або атрибути не дозволяють автоматичне визначення імені файлу, сервер використовує конфігурацію gitcvs.allBinary як налаштування за замовчуванням. Якщо встановлено gitcvs.allBinary, то файл, для якого не вказано інше, за замовчуванням використовуватиме режим -kb. В іншому випадку режим -k залишається порожнім. Але якщо для gitcvs.allBinary встановлено значення "guess", то правильний режим -k буде вгадано на основі вмісту файлу.

Для найкращої узгодженості з «cvs», ймовірно, найкраще змінити значення за замовчуванням, встановивши gitcvs.usecrlfattr на true, а gitcvs.allBinary на «guess».

ЗАЛЕЖНОСТІ

git-cvsserver залежить від DBD::SQLite.

GIT

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