1GIT-CVSSERVER(1) Git Manual GIT-CVSSERVER(1)
2
6 git-cvsserver - A CVS server emulator for git
7
9 SSH:
10 export CVS_SERVER="git cvsserver"
12 cvs -d :ext:user@server/path/repo.git co <HEAD_name>
13 pserver (/etc/inetd.conf):
16 cvspserver stream tcp nowait nobody /usr/bin/git-cvsserver git-cvsserver pserver
18 Usage:
21 git-cvsserver [options] [pserver|server] [<directory> ...]
23
26 All these options obviously only make sense if enforced by the server
27 side. They have been implemented to resemble the git-daemon(1) options
28 as closely as possible.
29 --base-path <path>
31 Prepend path to requested CVSROOT
32 --strict-paths
34 Don’t allow recursing into subdirectories
35 --export-all
37 Don’t check for gitcvs.enabled in config. You also have to specify
38 a list of allowed directories (see below) if you want to use this
39 option.
40 -V, --version
42 Print version information and exit
43 -h, -H, --help
45 Print usage information and exit
46 <directory>
48 You can specify a list of allowed directories. If no directories
49 are given, all are allowed. This is an additional restriction,
50 gitcvs access still needs to be enabled by the gitcvs.enabled
51 config option unless --export-all was given, too.
52
54 This application is a CVS emulation layer for git.
55 It is highly functional. However, not all methods are implemented, and
57 for those methods that are implemented, not all switches are
58 implemented.
59 Testing has been done using both the CLI CVS client, and the Eclipse
61 CVS plugin. Most functionality works fine with both of these clients.
62
64 Currently cvsserver works over SSH connections for read/write clients,
65 and over pserver for anonymous CVS access.
66 CVS clients cannot tag, branch or perform GIT merges.
68 git-cvsserver maps GIT branches to CVS modules. This is very different
70 from what most CVS users would expect since in CVS modules usually
71 represent one or more directories.
72
74 1. If you are going to offer anonymous CVS access via pserver, add a
75 line in /etc/inetd.conf like
76 cvspserver stream tcp nowait nobody git-cvsserver pserver
78 Note: Some inetd servers let you specify the name of the executable
80 independently of the value of argv[0] (i.e. the name the program
81 assumes it was executed with). In this case the correct line in
82 /etc/inetd.conf looks like
83 cvspserver stream tcp nowait nobody /usr/bin/git-cvsserver git-cvsserver pserver
85 No special setup is needed for SSH access, other than having GIT
87 tools in the PATH. If you have clients that do not accept the
88 CVS_SERVER environment variable, you can rename git-cvsserver to
89 cvs.
90 Note: Newer CVS versions (>= 1.12.11) also support specifying
92 CVS_SERVER directly in CVSROOT like
93 cvs -d ":ext;CVS_SERVER=git cvsserver:user@server/path/repo.git" co <HEAD_name>
95 This has the advantage that it will be saved in your CVS/Root files
97 and you don’t need to worry about always setting the correct
98 environment variable. SSH users restricted to git-shell don’t need
99 to override the default with CVS_SERVER (and shouldn’t) as
100 git-shell understands cvs to mean git-cvsserver and pretends that
101 the other end runs the real cvs better.
102 2. For each repo that you want accessible from CVS you need to edit
104 config in the repo and add the following section.
105 [gitcvs]
107 enabled=1
108 # optional for debugging
109 logfile=/path/to/logfile
110 Note: you need to ensure each user that is going to invoke
112 git-cvsserver has write access to the log file and to the database
113 (see Database Backend. If you want to offer write access over SSH,
114 the users of course also need write access to the git repository
115 itself.
116 You also need to ensure that each repository is "bare" (without a
118 git index file) for cvs commit to work. See gitcvs-migration(7).
119 All configuration variables can also be overridden for a specific
121 method of access. Valid method names are "ext" (for SSH access) and
122 "pserver". The following example configuration would disable
123 pserver access while still allowing access over SSH.
124 [gitcvs]
126 enabled=0
127 [gitcvs "ext"]
129 enabled=1
130 3. If you didn’t specify the CVSROOT/CVS_SERVER directly in the
133 checkout command, automatically saving it in your CVS/Root files,
134 then you need to set them explicitly in your environment. CVSROOT
135 should be set as per normal, but the directory should point at the
136 appropriate git repo. As above, for SSH clients not restricted to
137 git-shell, CVS_SERVER should be set to git-cvsserver.
138 export CVSROOT=:ext:user@server:/var/git/project.git
140 export CVS_SERVER="git cvsserver"
141 4. For SSH clients that will make commits, make sure their server-side
144 .ssh/environment files (or .bashrc, etc., according to their
145 specific shell) export appropriate values for GIT_AUTHOR_NAME,
146 GIT_AUTHOR_EMAIL, GIT_COMMITTER_NAME, and GIT_COMMITTER_EMAIL. For
147 SSH clients whose login shell is bash, .bashrc may be a reasonable
148 alternative.
149 5. Clients should now be able to check out the project. Use the CVS
151 module name to indicate what GIT head you want to check out. This
152 also sets the name of your newly checked-out directory, unless you
153 tell it otherwise with -d <dir_name>. For example, this checks out
154 master branch to the project-master directory:
155 cvs co -d project-master master
157
160 git-cvsserver uses one database per git head (i.e. CVS module) to store
161 information about the repository to maintain consistent CVS revision
162 numbers. The database needs to be updated (i.e. written to) after every
163 commit.
164 If the commit is done directly by using git (as opposed to using
166 git-cvsserver) the update will need to happen on the next repository
167 access by git-cvsserver, independent of access method and requested
168 operation.
169 That means that even if you offer only read access (e.g. by using the
171 pserver method), git-cvsserver should have write access to the database
172 to work reliably (otherwise you need to make sure that the database is
173 up-to-date any time git-cvsserver is executed).
174 By default it uses SQLite databases in the git directory, named
176 gitcvs.<module_name>.sqlite. Note that the SQLite backend creates
177 temporary files in the same directory as the database file on write so
178 it might not be enough to grant the users using git-cvsserver write
179 access to the database file without granting them write access to the
180 directory, too.
181 The database can not be reliably regenerated in a consistent form after
183 the branch it is tracking has changed. Example: For merged branches,
184 git-cvsserver only tracks one branch of development, and after a git
185 merge an incrementally updated database may track a different branch
186 than a database regenerated from scratch, causing inconsistent CVS
187 revision numbers. git-cvsserver has no way of knowing which branch it
188 would have picked if it had been run incrementally pre-merge. So if you
189 have to fully or partially (from old backup) regenerate the database,
190 you should be suspicious of pre-existing CVS sandboxes.
191 You can configure the database backend with the following configuration
193 variables:
194 Configuring database backend
196 git-cvsserver uses the Perl DBI module. Please also read its
197 documentation if changing these variables, especially about
198 DBI→connect().
199 gitcvs.dbname
201 Database name. The exact meaning depends on the selected database
202 driver, for SQLite this is a filename. Supports variable
203 substitution (see below). May not contain semicolons (;). Default:
204 %Ggitcvs.%m.sqlite
205 gitcvs.dbdriver
207 Used DBI driver. You can specify any available driver for this
208 here, but it might not work. cvsserver is tested with DBD::SQLite,
209 reported to work with DBD::Pg, and reported not to work with
210 DBD::mysql. Please regard this as an experimental feature. May not
211 contain colons (:). Default: SQLite
212 gitcvs.dbuser
214 Database user. Only useful if setting dbdriver, since SQLite has no
215 concept of database users. Supports variable substitution (see
216 below).
217 gitcvs.dbpass
219 Database password. Only useful if setting dbdriver, since SQLite
220 has no concept of database passwords.
221 gitcvs.dbTableNamePrefix
223 Database table name prefix. Supports variable substitution (see
224 below). Any non-alphabetic characters will be replaced with
225 underscores.
226 All variables can also be set per access method, see above.
228 Variable substitution
230 In dbdriver and dbuser you can use the following variables:
231 %G
233 git directory name
234 %g
236 git directory name, where all characters except for
237 alpha-numeric ones, ., and - are replaced with _ (this should
238 make it easier to use the directory name in a filename if
239 wanted)
240 %m
242 CVS module/git head name
243 %a
245 access method (one of "ext" or "pserver")
246 %u
248 Name of the user running git-cvsserver. If no name can be
249 determined, the numeric uid is used.
250
252 These variables obviate the need for command-line options in some
253 circumstances, allowing easier restricted usage through git-shell.
254 GIT_CVSSERVER_BASE_PATH takes the place of the argument to --base-path.
256 GIT_CVSSERVER_ROOT specifies a single-directory whitelist. The
258 repository must still be configured to allow access through
259 git-cvsserver, as described above.
260 When these environment variables are set, the corresponding
262 command-line arguments may not be used.
263
265 To get a checkout with the Eclipse CVS client:
266 1. Select "Create a new project → From CVS checkout"
268 2. Create a new location. See the notes below for details on how to
270 choose the right protocol.
271 3. Browse the modules available. It will give you a list of the heads
273 in the repository. You will not be able to browse the tree from
274 there. Only the heads.
275 4. Pick HEAD when it asks what branch/tag to check out. Untick the
277 "launch commit wizard" to avoid committing the .project file.
278 Protocol notes: If you are using anonymous access via pserver, just
280 select that. Those using SSH access should choose the ext protocol, and
281 configure ext access on the Preferences→Team→CVS→ExtConnection pane.
282 Set CVS_SERVER to "git cvsserver". Note that password support is not
283 good when using ext, you will definitely want to have SSH keys setup.
284 Alternatively, you can just use the non-standard extssh protocol that
286 Eclipse offer. In that case CVS_SERVER is ignored, and you will have to
287 replace the cvs utility on the server with git-cvsserver or manipulate
288 your .bashrc so that calling cvs effectively calls git-cvsserver.
289
291 · CVS 1.12.9 on Debian
292 · CVS 1.11.17 on MacOSX (from Fink package)
294 · Eclipse 3.0, 3.1.2 on MacOSX (see Eclipse CVS Client Notes)
296 · TortoiseCVS
298
300 All the operations required for normal use are supported, including
301 checkout, diff, status, update, log, add, remove, commit. Legacy
302 monitoring operations are not supported (edit, watch and related).
303 Exports and tagging (tags and branches) are not supported at this
304 stage.
305 CRLF Line Ending Conversions
307 By default the server leaves the -k mode blank for all files, which
308 causes the cvs client to treat them as a text files, subject to crlf
309 conversion on some platforms.
310 You can make the server use crlf attributes to set the -k modes for
312 files by setting the gitcvs.usecrlfattr config variable. In this case,
313 if crlf is explicitly unset (-crlf), then the server will set -kb mode
314 for binary files. If crlf is set, then the -k mode will explicitly be
315 left blank. See also gitattributes(5) for more information about the
316 crlf attribute.
317 Alternatively, if gitcvs.usecrlfattr config is not enabled or if the
319 crlf attribute is unspecified for a filename, then the server uses the
320 gitcvs.allbinary config for the default setting. If gitcvs.allbinary is
321 set, then file not otherwise specified will default to -kb mode.
322 Otherwise the -k mode is left blank. But if gitcvs.allbinary is set to
323 "guess", then the correct -k mode will be guessed based on the contents
324 of the file.
325 For best consistency with cvs, it is probably best to override the
327 defaults by setting gitcvs.usecrlfattr to true, and gitcvs.allbinary to
328 "guess".
329
331 git-cvsserver depends on DBD::SQLite.
332
334 This program is copyright The Open University UK - 2006.
335 Authors:
337 · Martyn Smith <martyn@catalyst.net.nz[1]>
339 · Martin Langhoff <martin@catalyst.net.nz[2]>
341 with ideas and patches from participants of the git-list
343 <git@vger.kernel.org[3]>.
344
346 Documentation by Martyn Smith <martyn@catalyst.net.nz[1]>, Martin
347 Langhoff <martin@catalyst.net.nz[2]>, and Matthias Urlichs
348 <smurf@smurf.noris.de[4]>.
349
351 Part of the git(1) suite
352
354 1. martyn@catalyst.net.nz
355 mailto:martyn@catalyst.net.nz
356 2. martin@catalyst.net.nz
358 mailto:martin@catalyst.net.nz
359 3. git@vger.kernel.org
361 mailto:git@vger.kernel.org
362 4. smurf@smurf.noris.de
364 mailto:smurf@smurf.noris.de
365Git 1.7.1 08/16/2017 GIT-CVSSERVER(1)