![[tokkee]](http://tokkee.org/images/avatar.png){kind=avatar}
index 952635d809ba95b6bb747e30b2edb282169e2812..258a62f7e9e91249b42b85df2880b4b2e07de11c 100644 (file)
SYNOPSIS
--------
+
+SSH:
+
[verse]
export CVS_SERVER=git-cvsserver
'cvs' -d :ext:user@server/path/repo.git co <HEAD_name>
+pserver (/etc/inetd.conf):
+
+[verse]
+cvspserver stream tcp nowait nobody /usr/bin/git-cvsserver git-cvsserver pserver
+
+Usage:
+
+[verse]
+'git-cvsserver' [options] [pserver|server] [<directory> ...]
+
+OPTIONS
+-------
+
+All these options obviously only make sense if enforced by the server side.
+They have been implemented to resemble the gitlink:git-daemon[1] options as
+closely as possible.
+
+--base-path <path>::
+Prepend 'path' to requested CVSROOT
+
+--strict-paths::
+Don't allow recursing into subdirectories
+
+--export-all::
+Don't check for `gitcvs.enabled` in config. You also have to specify a list
+of allowed directories (see below) if you want to use this option.
+
+--version, -V::
+Print version information and exit
+
+--help, -h, -H::
+Print usage information and exit
+
+<directory>::
+You can specify a list of allowed directories. If no directories
+are given, all are allowed. This is an additional restriction, gitcvs
+access still needs to be enabled by the `gitcvs.enabled` config option
+unless '--export-all' was given, too.
+
+
DESCRIPTION
-----------
CVS clients cannot tag, branch or perform GIT merges.
+git-cvsserver maps GIT branches to CVS modules. This is very different
+from what most CVS users would expect since in CVS modules usually represent
+one or more directories.
+
INSTALLATION
------------
1. If you are going to offer anonymous CVS access via pserver, add a line in
/etc/inetd.conf like
-
++
+--
+------
cvspserver stream tcp nowait nobody git-cvsserver pserver
- Note: In some cases, you need to pass the 'pserver' argument twice for
- git-cvsserver to see it. So the line would look like
-
- cvspserver stream tcp nowait nobody git-cvsserver pserver pserver
-
- No special setup is needed for SSH access, other than having GIT tools
- in the PATH. If you have clients that do not accept the CVS_SERVER
- env variable, you can rename git-cvsserver to cvs.
-
+------
+Note: Some inetd servers let you specify the name of the executable
+independently of the value of argv[0] (i.e. the name the program assumes
+it was executed with). In this case the correct line in /etc/inetd.conf
+looks like
+
+------
+ cvspserver stream tcp nowait nobody /usr/bin/git-cvsserver git-cvsserver pserver
+
+------
+No special setup is needed for SSH access, other than having GIT tools
+in the PATH. If you have clients that do not accept the CVS_SERVER
+environment variable, you can rename git-cvsserver to cvs.
+
+Note: Newer CVS versions (>= 1.12.11) also support specifying
+CVS_SERVER directly in CVSROOT like
+
+------
+cvs -d ":ext;CVS_SERVER=git-cvsserver:user@server/path/repo.git" co <HEAD_name>
+------
+This has the advantage that it will be saved in your 'CVS/Root' files and
+you don't need to worry about always setting the correct environment
+variable.
+--
2. For each repo that you want accessible from CVS you need to edit config in
the repo and add the following section.
-
++
+--
+------
[gitcvs]
enabled=1
# optional for debugging
logfile=/path/to/logfile
- Note: you need to ensure each user that is going to invoke git-cvsserver has
- write access to the log file and to the git repository. When offering anon
- access via pserver, this means that the nobody user should have write access
- to at least the sqlite database at the root of the repository.
+------
+Note: you need to ensure each user that is going to invoke git-cvsserver has
+write access to the log file and to the database (see
+<<dbbackend,Database Backend>>. If you want to offer write access over
+SSH, the users of course also need write access to the git repository itself.
+
+[[configaccessmethod]]
+All configuration variables can also be overridden for a specific method of
+access. Valid method names are "ext" (for SSH access) and "pserver". The
+following example configuration would disable pserver access while still
+allowing access over SSH.
+------
+ [gitcvs]
+ enabled=0
+ [gitcvs "ext"]
+ enabled=1
+------
+--
3. On the client machine you need to set the following variables.
CVSROOT should be set as per normal, but the directory should point at the
appropriate git repo. For example:
++
+--
+For SSH access, CVS_SERVER should be set to git-cvsserver
- For SSH access, CVS_SERVER should be set to git-cvsserver
-
- Example:
+Example:
+------
export CVSROOT=:ext:user@server:/var/git/project.git
export CVS_SERVER=git-cvsserver
-
+------
+--
4. For SSH clients that will make commits, make sure their .bashrc file
sets the GIT_AUTHOR and GIT_COMMITTER variables.
5. Clients should now be able to check out the project. Use the CVS 'module'
name to indicate what GIT 'head' you want to check out. Example:
-
++
+------
cvs co -d project-master master
+------
+
+[[dbbackend]]
+Database Backend
+----------------
+
+git-cvsserver uses one database per git head (i.e. CVS module) to
+store information about the repository for faster access. The
+database doesn't contain any persistent data and can be completely
+regenerated from the git repository at any time. The database
+needs to be updated (i.e. written to) after every commit.
+
+If the commit is done directly by using git (as opposed to
+using git-cvsserver) the update will need to happen on the
+next repository access by git-cvsserver, independent of
+access method and requested operation.
+
+That means that even if you offer only read access (e.g. by using
+the pserver method), git-cvsserver should have write access to
+the database to work reliably (otherwise you need to make sure
+that the database if up-to-date all the time git-cvsserver is run).
+
+By default it uses SQLite databases in the git directory, named
+`gitcvs.<module_name>.sqlite`. Note that the SQLite backend creates
+temporary files in the same directory as the database file on
+write so it might not be enough to grant the users using
+git-cvsserver write access to the database file without granting
+them write access to the directory, too.
+
+You can configure the database backend with the following
+configuration variables:
+
+Configuring database backend
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+git-cvsserver uses the Perl DBI module. Please also read
+its documentation if changing these variables, especially
+about `DBI->connect()`.
+
+gitcvs.dbname::
+ Database name. The exact meaning depends on the
+ used database driver, for SQLite this is a filename.
+ Supports variable substitution (see below). May
+ not contain semicolons (`;`).
+ Default: '%Ggitcvs.%m.sqlite'
+
+gitcvs.dbdriver::
+ Used DBI driver. You can specify any available driver
+ for this here, but it might not work. cvsserver is tested
+ with 'DBD::SQLite', reported to work with
+ 'DBD::Pg', and reported *not* to work with 'DBD::mysql'.
+ Please regard this as an experimental feature. May not
+ contain double colons (`:`).
+ Default: 'SQLite'
+
+gitcvs.dbuser::
+ Database user. Only useful if setting `dbdriver`, since
+ SQLite has no concept of database users. Supports variable
+ substitution (see below).
+
+gitcvs.dbpass::
+ Database password. Only useful if setting `dbdriver`, since
+ SQLite has no concept of database passwords.
+
+All variables can also be set per access method, see <<configaccessmethod,above>>.
+
+Variable substitution
+^^^^^^^^^^^^^^^^^^^^^
+In `dbdriver` and `dbuser` you can use the following variables:
+
+%G::
+ git directory name
+%g::
+ git directory name, where all characters except for
+ alpha-numeric ones, `.`, and `-` are replaced with
+ `_` (this should make it easier to use the directory
+ name in a filename if wanted)
+%m::
+ CVS module/git head name
+%a::
+ access method (one of "ext" or "pserver")
+%u::
+ Name of the user running git-cvsserver.
+ If no name can be determined, the
+ numeric uid is used.
Eclipse CVS Client Notes
------------------------
Protocol notes: If you are using anonymous access via pserver, just select that.
Those using SSH access should choose the 'ext' protocol, and configure 'ext'
access on the Preferences->Team->CVS->ExtConnection pane. Set CVS_SERVER to
-'git-cvsserver'. Not that password support is not good when using 'ext',
+'git-cvsserver'. Note that password support is not good when using 'ext',
you will definitely want to have SSH keys setup.
Alternatively, you can just use the non-standard extssh protocol that Eclipse
offer. In that case CVS_SERVER is ignored, and you will have to replace
-the cvs utility on the server with git-cvsserver or manipulate your .bashrc
+the cvs utility on the server with git-cvsserver or manipulate your `.bashrc`
so that calling 'cvs' effectively calls git-cvsserver.
Clients known to work
---------------------
-CVS 1.12.9 on Debian
-CVS 1.11.17 on MacOSX (from Fink package)
-Eclipse 3.0, 3.1.2 on MacOSX (see Eclipse CVS Client Notes)
-TortoiseCVS
+- CVS 1.12.9 on Debian
+- CVS 1.11.17 on MacOSX (from Fink package)
+- Eclipse 3.0, 3.1.2 on MacOSX (see Eclipse CVS Client Notes)
+- TortoiseCVS
Operations supported
--------------------
Legacy monitoring operations are not supported (edit, watch and related).
Exports and tagging (tags and branches) are not supported at this stage.
-The server will set the -k mode to binary when relevant. In proper GIT
-tradition, the contents of the files are always respected.
-No keyword expansion or newline munging is supported.
+The server should set the '-k' mode to binary when relevant, however,
+this is not really implemented yet. For now, you can force the server
+to set '-kb' for all files by setting the `gitcvs.allbinary` config
+variable. In proper GIT tradition, the contents of the files are
+always respected. No keyword expansion or newline munging is supported.
Dependencies
------------
This program is copyright The Open University UK - 2006.
-Authors: Martyn Smith <martyn@catalyst.net.nz>
- Martin Langhoff <martin@catalyst.net.nz>
- with ideas and patches from participants of the git-list <git@vger.kernel.org>.
+Authors:
+
+- Martyn Smith <martyn@catalyst.net.nz>
+- Martin Langhoff <martin@catalyst.net.nz>
+
+with ideas and patches from participants of the git-list <git@vger.kernel.org>.
Documentation
--------------
-Documentation by Martyn Smith <martyn@catalyst.net.nz> and Martin Langhoff <martin@catalyst.net.nz> Matthias Urlichs <smurf@smurf.noris.de>.
+Documentation by Martyn Smith <martyn@catalyst.net.nz>, Martin Langhoff <martin@catalyst.net.nz>, and Matthias Urlichs <smurf@smurf.noris.de>.
GIT
---