git-cvsserver - онлайн в облаке

ПРОГРАММА:

ИМЯ

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

СИНТАКСИС

СШ:

экспорт CVS_SERVER = "git cvsserver"
CVS -d: ext: user@server/path/repo.git co

сервер (/etc/inetd.conf):

поток cvspserver tcp nowait никто / usr / bin / git-cvsserver git-cvsserver pserver

Применение:

git-cvsserver [параметры] [сервер | сервер] [ ...]

ДОПОЛНИТЕЛЬНЫЕ УСЛУГИ, НЕ ВКЛЮЧЕННЫЕ В ПАКЕТ

Очевидно, что все эти параметры имеют смысл только в том случае, если они выполняются на стороне сервера. Они были
реализовано, чтобы напоминать git-демон(1) варианты как можно точнее.

--base-path
Подготовить путь запросить CVSROOT

--строгие пути
Не разрешать повторный переход в подкаталоги

--экспорт-все
Не проверяйте gitcvs.enabled в конфигурации. Вы также должны указать список разрешенных
каталоги (см. ниже), если вы хотите использовать эту опцию.

-V, --версия
Распечатать информацию о версии и выйти

-ч, -ч, --помощь
Распечатать информацию об использовании и выйти


Вы можете указать список разрешенных каталогов. Если каталоги не указаны, все
разрешается. Это дополнительное ограничение, доступ к gitcvs по-прежнему должен быть включен
параметр конфигурации gitcvs.enabled, если --экспорт-все тоже был дан.

ОПИСАНИЕ

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

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

Тестирование проводилось с использованием как клиента CLI CVS, так и подключаемого модуля Eclipse CVS. Самый
функциональность отлично работает с обоими из этих клиентов.

ОГРАНИЧЕНИЯ

Клиенты CVS не могут помечать, разветвлять или выполнять слияние Git.

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

МОНТАЖ

1. Если вы собираетесь предлагать доступ к CVS через pserver, добавьте строку в /etc/inetd.conf, например

поток cvspserver tcp теперь никто не git-cvsserver pserver

Примечание. Некоторые серверы inetd позволяют указывать имя исполняемого файла независимо от
значение argv [0] (то есть имя, с которым программа предполагает, что она была выполнена). В этом
если правильная строка в /etc/inetd.conf выглядит как

поток cvspserver tcp nowait никто / usr / bin / git-cvsserver git-cvsserver pserver

По умолчанию pserve предоставляет только анонимный доступ. Для совершения вам придется
создать учетные записи pserver, просто добавьте параметр gitcvs.authdb в файл конфигурации
репозитории, в которые cvsserver должен разрешать запись, например:

[gitcvs]
authdb = / и т.д. / cvsserver / passwd

Формат этих файлов - имя пользователя, за которым следует зашифрованный пароль, например:

myuser: $ 1Oyx5r9mdGZ2
myuser: $ 1 $ BA) @ $ vbnMJMDym7tA32AamXrm./

Вы можете использовать htpasswd средство, которое поставляется с Apache для создания этих файлов, но
Метод шифрования MD5 Apache отличается от метода crypt () большинства библиотек C.
функция, поэтому не используйте параметр -m.

В качестве альтернативы вы можете создать пароль с помощью оператора perl crypt ():

perl -e 'мой ($ user, $ pass) = @ARGV; printf "% s:% s \ n", $ user, crypt ($ user, $ pass) 'пароль $ USER

Затем укажите свой пароль с помощью метода pserver, например:

cvs -d: pserver: someuser: somepassword сервер / путь / repo.git co

Для доступа по 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

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

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

[gitcvs]
включенной = 1
# необязательно для отладки
logFile = / путь / к / файлу журнала

Примечание: вам необходимо убедиться, что каждый пользователь, который будет вызывать git-cvsserver написал
доступ к файлу журнала и базе данных (см. Серверная часть базы данных. Если вы хотите предложить
доступ на запись через SSH, пользователям, конечно же, также нужен доступ на запись в Git
сам репозиторий.

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

Все переменные конфигурации также могут быть переопределены для определенного метода доступа.
Допустимые имена методов: ext (для доступа по SSH) и pserver. Следующий пример
конфигурация отключит доступ к серверу, но по-прежнему разрешает доступ через SSH.

[gitcvs]
включенной = 0

[gitcvs "ext"]
включенной = 1

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

экспорт CVSROOT =: ext: user @ server: /var/git/project.git
экспорт 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 модуль имя для
указать, что Git вы хотите проверить. Это также устанавливает имя вашего нового
извлеченный каталог, если вы не укажете иное с помощью -d . Например,
это проверяет мастер ветвь в директорию project-master:

cvs co -d мастер-мастер проекта

DATABASE НАЗАД

git-cvsserver использует одну базу данных на заголовок Git (т.е. модуль CVS) для хранения информации о
репозиторий для поддержания согласованных номеров ревизий CVS. База данных должна быть
обновляется (т.е. записывается) после каждой фиксации.

Если фиксация выполняется напрямую с помощью git (в отличие от использования git-cvsserver) обновление
должно произойти при следующем доступе к репозиторию git-cvsserver, независимо от доступа
метод и запрошенная операция.

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

По умолчанию он использует базы данных SQLite в каталоге Git с именем
gitcvs. .sqlite. Обратите внимание, что серверная часть SQLite создает временные файлы в
тот же каталог, что и файл базы данных при записи, поэтому этого может быть недостаточно для предоставления пользователям
через git-cvsserver доступ на запись к файлу базы данных без предоставления им доступа на запись
в каталог тоже.

База данных не может быть надежно восстановлена ​​в согласованной форме после того, как ветка будет
отслеживание изменилось. Пример: для объединенных ветвей git-cvsserver отслеживает только одну ветку
развития, а после мерзавец слияние постепенно обновляемая база данных может отслеживать
ветвь, отличная от ветки базы данных, созданной с нуля, что приводит к несогласованности CVS
номера ревизий. git-cvsserver не может узнать, какую ветку он выбрал бы, если бы
он запускался постепенно перед слиянием. Так что если вам нужно полностью или частично (из старых
backup) регенерировать базу данных, вы должны с подозрением относиться к уже существующим песочницам 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 определяет белый список для одного каталога. Репозиторий все еще должен быть
настроен для разрешения доступа через git-cvsserver, как описано выше.

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

ECLIPSE CVS КЛИЕНТ ПРИМЕЧАНИЯ

Чтобы оформить заказ с помощью клиента Eclipse CVS:

1. Выберите «Создать новый проект → Из оформления CVS».

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

3. Просмотрите модули доступный. Это даст вам список голов в репозитории.
Вы не сможете просматривать дерево оттуда. Только головы.

4. Выберите ГОЛОВА когда он спрашивает, какую ветку / тег проверить. Снимите галочку с "мастера запуска фиксации"
чтобы избежать фиксации файла .project.

Примечания к протоколу: если вы используете анонимный доступ через pserver, просто выберите его. Те
используя SSH-доступ, следует выбрать Ext протокол и настроить Ext доступ на
Настройки → Команда → CVS → Панель ExtConnection. Установите CVS_SERVER в "git cvsserver". Обратите внимание, что
поддержка паролей не очень хороша при использовании Ext, вам обязательно захочется иметь ключи SSH
настроить.

В качестве альтернативы вы можете просто использовать нестандартный протокол extssh, предлагаемый Eclipse. В
в этом случае CVS_SERVER игнорируется, и вам придется заменить утилиту cvs на
сервер с git-cvsserver или манипулируйте своим .bashrc так, чтобы вызов CVS эффективно звонит
git-cvsserver.

клиентов KNOWN К РАБОТА

· CVS 1.12.9 для Debian

· CVS 1.11.17 для MacOSX (из пакета Fink)

· Eclipse 3.0, 3.1.2 в MacOSX (см. Примечания к Eclipse CVS Client)

· ЧерепахаCVS

ОПЕРАЦИИ ПОДДЕРЖКА

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

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

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

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

Устаревшие операции мониторинга не поддерживаются (редактирование, просмотр и т.п.). Экспорт и
теги (теги и ветки) на данном этапе не поддерживаются.

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

Вы можете заставить сервер использовать атрибуты преобразования конца строки для установки -k режимы для
файлы, установив переменную конфигурации gitcvs.usecrlfattr. Видеть gitattributes(5) подробнее
информация о преобразовании конца строки.

В качестве альтернативы, если конфигурация gitcvs.usecrlfattr не включена или атрибуты не позволяют
автоматическое определение имени файла, тогда сервер использует конфигурацию gitcvs.allBinary для
настройка по умолчанию. Если установлен gitcvs.allBinary, то файл, не указанный иначе, будет
по умолчанию -КБ режим. В противном случае -k режим оставлен пустым. Но если установлен gitcvs.allBinary
"угадать", то правильный -k режим будет угадан на основе содержимого файла.

Для наилучшего соответствия с CVS, вероятно, лучше изменить настройки по умолчанию, установив
Для gitcvs.usecrlfattr значение true, а для gitcvs.allBinary - "угадывать".

ЗАВИСИМОСТИ

git-cvsserver зависит от DBD :: SQLite.

GIT

Часть мерзавец(1) люкс

Используйте git-cvsserver в Интернете с помощью сервисов onworks.net