-------
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
+They have been implemented to resemble the linkgit:git-daemon[1] options as
closely as possible.
--base-path <path>::
------
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
Legacy monitoring operations are not supported (edit, watch and related).
Exports and tagging (tags and branches) are not supported at this stage.
-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.
+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
---
-Part of the gitlink:git[7] suite
+Part of the linkgit:git[7] suite
projects / thirdparty / git.git / blobdiff