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.  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 to maintain consistent
CVS revision numbers. 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.

The database cannot be reliably regenerated in a
consistent form after the branch it is tracking has changed.
Example: For merged branches, 'git-cvsserver' only tracks
one branch of development, and after a 'git merge' an
incrementally updated database may track a different branch
than a database regenerated from scratch, causing inconsistent
CVS revision numbers. `git-cvsserver` has no way of knowing which
branch it would have picked if it had been run incrementally
pre-merge. So if you have to fully or partially (from old
backup) regenerate the database, you should be suspicious
of pre-existing CVS sandboxes.

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
	alphanumeric 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")