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 linkgit: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.
+
+-V::
+--version::
+Print version information and exit
+
+-h::
+-H::
+--help::
+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
------------
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
+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 git-cvsserver pserver pserver
+ 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
-env variable, you can rename git-cvsserver to cvs.
+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. SSH users restricted to 'git-shell' don't need to override the default
+with CVS_SERVER (and shouldn't) as 'git-shell' understands `cvs` to mean
+'git-cvsserver' and pretends that the other end runs the real 'cvs' better.
--
2. For each repo that you want accessible from CVS you need to edit config in
the repo and add the following section.
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.
+
+You also need to ensure that each repository is "bare" (without a git index
+file) for `cvs commit` to work. See linkgit:gitcvs-migration[7].
+
+[[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:
+3. If you didn't specify the CVSROOT/CVS_SERVER directly in the checkout command,
+ automatically saving it in your 'CVS/Root' files, then you need to set them
+ explicitly in your environment. CVSROOT should be set as per normal, but the
+ directory should point at the appropriate git repo. As above, for SSH clients
+ _not_ restricted to 'git-shell', CVS_SERVER should be set to 'git-cvsserver'.
+
--
-For SSH access, CVS_SERVER should be set to git-cvsserver
-
-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.
+4. For SSH clients that will make commits, make sure their server-side
+ .ssh/environment files (or .bashrc, etc., according to their specific shell)
+ export appropriate values for GIT_AUTHOR_NAME, GIT_AUTHOR_EMAIL,
+ GIT_COMMITTER_NAME, and GIT_COMMITTER_EMAIL. For SSH clients whose login
+ shell is bash, .bashrc may be a reasonable alternative.
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:
+ name to indicate what GIT 'head' you want to check out. This also sets the
+ name of your newly checked-out directory, unless you tell it otherwise with
+ `-d <dir_name>`. For example, this checks out 'master' branch to the
+ `project-master` directory:
+
------
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 is up-to-date any time 'git-cvsserver' is executed).
+
+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
+ selected 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 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.
+
+gitcvs.dbTableNamePrefix::
+ Database table name prefix. Supports variable substitution
+ (see below). Any non-alphabetic characters will be replaced
+ with underscores.
+
+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
-so that calling 'cvs' effectively calls git-cvsserver.
+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
---------------------
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.
+CRLF Line Ending Conversions
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+By default the server leaves the '-k' mode blank for all files,
+which causes the cvs client to treat them as a text files, subject
+to crlf conversion on some platforms.
+
+You can make the server use `crlf` attributes to set the '-k' modes
+for files by setting the `gitcvs.usecrlfattr` config variable.
+In this case, if `crlf` is explicitly unset ('-crlf'), then the
+server will set '-kb' mode for binary files. If `crlf` is set,
+then the '-k' mode will explicitly be left blank. See
+also linkgit:gitattributes[5] for more information about the `crlf`
+attribute.
+
+Alternatively, if `gitcvs.usecrlfattr` config is not enabled
+or if the `crlf` attribute is unspecified for a filename, then
+the server uses the `gitcvs.allbinary` config for the default setting.
+If `gitcvs.allbinary` is set, then file not otherwise
+specified will default to '-kb' mode. Otherwise the '-k' mode
+is left blank. But if `gitcvs.allbinary` is set to "guess", then
+the correct '-k' mode will be guessed based on the contents of
+the file.
+
+For best consistency with 'cvs', it is probably best to override the
+defaults by setting `gitcvs.usecrlfattr` to true,
+and `gitcvs.allbinary` to "guess".
Dependencies
------------
-
-git-cvsserver depends on DBD::SQLite.
+'git-cvsserver' depends on DBD::SQLite.
Copyright and Authors
---------------------
GIT
---
-Part of the gitlink:git[7] suite
+Part of the linkgit:git[1] suite