with the -d option (or -B if your system supports it).

Preferably use the system specific utility that manages password hash
creation in your platform (e.g. mkpasswd in Linux, encrypt in OpenBSD or
pwhash in NetBSD) and paste it in the right location.

Then provide your password via the pserver method, for example:

------
   cvs -d:pserver:someuser:somepassword@server:/path/repo.git co <HEAD_name>
------

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.  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.
+
--
------
   [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 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. 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'.
+
--
------
   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 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.  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