------
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.
+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.
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
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).
+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
gitcvs.dbname::
Database name. The exact meaning depends on the
- used database driver, for SQLite this is a filename.
+ selected database driver, for SQLite this is a filename.
Supports variable substitution (see below). May
not contain semicolons (`;`).
Default: '%Ggitcvs.%m.sqlite'
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 (`:`).
+ contain colons (`:`).
Default: 'SQLite'
gitcvs.dbuser::
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