git-cvsserver

Имя

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 stream tcp nowait nobody /usr/bin/git-cvsserver git-cvsserver pserver

Использование:

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

Описание

Данное приложение — это слой эмуляции CVS для Git.

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

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

Параметры

Все эти параметры, очевидно, имеют смысл только в случае их применения со стороны сервера. Они были реализованы для максимального соответствия параметрам git-daemon[1].

--base-path <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 модули обычно представляют собой один или несколько каталогов.

Установка

Если вы планируете предоставить доступ к CVS через pserver, добавьте строку в /etc/inetd.conf:
cvspserver stream tcp nowait nobody git-cvsserver pserver
Примечание: Некоторые серверы inetd позволяют вам указать имя исполняемого файла независимо от значения argv[0] (т. е. имени, которое программа предполагает, что она была запущена с). В этом случае правильная строка в /etc/inetd.conf выглядит следующим образом:
cvspserver stream 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 лучше.
Для каждого репозитория, к которому вы хотите получить доступ через CVS, вам необходимо отредактировать конфигурацию репозитория и добавить следующий раздел.
[gitcvs] enabled=1 # optional for debugging logFile=/path/to/logfile
Примечание: вам нужно убедиться, что каждый пользователь, который будет вызывать git-cvsserver, имеет права записи в лог-файл и в базу данных (см. Бэкенд базы данных). Если вы хотите предоставить права записи по SSH, пользователям, конечно же, также нужны права записи в сам Git-репозиторий.

Также необходимо убедиться, что каждый репозиторий является «голым» (без файла индекса Git), чтобы cvs commit работал. См. gitcvs-migration[7].

Все переменные конфигурации также могут быть переопределены для конкретного метода доступа. Действительные имена методов — «ext» (для доступа по SSH) и «pserver». Следующий пример конфигурации отключит доступ pserver, но позволит доступ по SSH.
[gitcvs] enabled=0 [gitcvs "ext"] enabled=1
Если вы не указали CVSROOT/CVS_SERVER напрямую в команде checkout, автоматически сохраняя его в ваших CVS/Root файлах, вам нужно явно установить их в вашей среде. CVSROOT должен быть установлен как обычно, но каталог должен указывать на соответствующий Git-репозиторий. Как и выше, для SSH-клиентов not ограниченных git-shell, CVS_SERVER должен быть установлен в git-cvsserver.
export CVSROOT=:ext:user@server:/var/git/project.git export CVS_SERVER="git cvsserver"
Для SSH-клиентов, которые будут совершать коммиты, убедитесь, что их файлы .ssh/environment (или .bashrc и т. д. в соответствии с их конкретной оболочкой) экспортируют соответствующие значения для GIT_AUTHOR_NAME, GIT_AUTHOR_EMAIL, GIT_COMMITTER_NAME и GIT_COMMITTER_EMAIL. Для SSH-клиентов, чья оболочка входа — bash, .bashrc может быть разумной альтернативой.
Теперь клиенты должны иметь возможность загрузить проект. Используйте имя CVS module для обозначения Git-ветви head которую вы хотите загрузить. Это также устанавливает имя вашего только что загруженного каталога, если вы не укажете иначе с помощью -d <dir-name> Например, это загружает ветку 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.<module-name>.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. Если имя определить нельзя, используется числовой идентификатор пользователя.

Окружение

Эти переменные исключают необходимость использования опций командной строки в некоторых случаях, что позволяет проще ограничить использование через git-shell.

GIT_CVSSERVER_BASE_PATH: Эта переменная заменяет аргумент --base-path.
GIT_CVSSERVER_ROOT: Эта переменная задаёт единственную директорию, заменяющую список аргументов <directory>.... Репозиторий всё ещё требует опцию конфигурации gitcvs.enabled, если не указана --export-all.

Если эти переменные среды установлены, соответствующие аргументы командной строки использовать нельзя.

Заметки к Eclipse CVS-клиенту

Для получения отчета с помощью клиента Eclipse CVS:

Выберите «Создать новый проект → Из CVS-отчёта»
Создайте новое расположение. См. примечания ниже, чтобы узнать, как выбрать нужный протокол.
Просмотрите доступные modules. Он предоставит вам список хедов в репозитории. Вы не сможете просмотреть дерево оттуда. Только хеды.
Выберите HEAD при запросе, какую ветвь/метку вы хотите проверить. Снимите флажок «Запустить мастер коммита», чтобы избежать коммита файла .project.

Примечания к протоколу: Если вы используете анонимный доступ через pserver, просто выберите его. Те, кто используют доступ через SSH, должны выбрать протокол ext, и настроить доступ ext в окне Preferences→Team→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, add, remove, commit.

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

Обратите внимание, что есть два способа получить checkout определённой ветви. Как описано на этой странице, параметр «модуль» в cvs checkout интерпретируется как имя ветви, и он становится основной ветвью. Он остаётся основной ветвью для данной песочницы, даже если вы временно сделаете другую ветвь активной с помощью cvs update -r. В качестве альтернативы, аргумент -r может указать на другую ветвь для фактического checkout, даже если модуль всё ещё является «основной» ветвью. Компромиссы (как реализованы в данный момент): каждый новый «модуль» создаёт новую базу данных на диске с историей для данного модуля, и после создания базы данных операции с этой основной ветвью выполняются быстро. Или в качестве альтернативы, -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.

© 2005–2026 Linus Torvalds and others
Licensed under the GNU General Public License version 2.
https://git-scm.com/docs/git-cvsserver