AmigActive 21

home *** CD-ROM | disk | FTP | other *** search

/ AmigActive 21 / AACD 21.iso / AACD / Programming / CVS / doc / cvs.info-2 < prev next >

Wrap

Text File | 2001-04-27 | 48.3 KB | 1,116 lines

This is cvs.info, produced by makeinfo version 4.0 from cvs.texinfo. START-INFO-DIR-ENTRY * CVS: (cvs). Concurrent Versions System END-INFO-DIR-ENTRY Copyright (C) 1992, 1993 Signum Support AB Copyright (C) 1993, 1994 Free Software Foundation, Inc. Permission is granted to make and distribute verbatim copies of this manual provided the copyright notice and this permission notice are preserved on all copies. Permission is granted to copy and distribute modified versions of this manual under the conditions for verbatim copying, provided also that the entire resulting derived work is distributed under the terms of a permission notice identical to this one. Permission is granted to copy and distribute translations of this manual into another language, under the above conditions for modified versions, except that this permission notice may be stated in a translation approved by the Free Software Foundation. File: cvs.info, Node: Intro administrative files, Next: Multiple repositories, Prev: Working directory storage, Up: Repository The administrative files ======================== The directory `$CVSROOT/CVSROOT' contains some "administrative files". *Note Administrative files::, for a complete description. You can use CVS without any of these files, but some commands work better when at least the `modules' file is properly set up. The most important of these files is the `modules' file. It defines all modules in the repository. This is a sample `modules' file. CVSROOT CVSROOT modules CVSROOT modules cvs gnu/cvs rcs gnu/rcs diff gnu/diff tc yoyodyne/tc The `modules' file is line oriented. In its simplest form each line contains the name of the module, whitespace, and the directory where the module resides. The directory is a path relative to `$CVSROOT'. The last four lines in the example above are examples of such lines. The line that defines the module called `modules' uses features that are not explained here. *Note modules::, for a full explanation of all the available features. Editing administrative files ---------------------------- You edit the administrative files in the same way that you would edit any other module. Use `cvs checkout CVSROOT' to get a working copy, edit it, and commit your changes in the normal way. It is possible to commit an erroneous administrative file. You can often fix the error and check in a new revision, but sometimes a particularly bad error in the administrative file makes it impossible to commit new revisions. File: cvs.info, Node: Multiple repositories, Next: Creating a repository, Prev: Intro administrative files, Up: Repository Multiple repositories ===================== In some situations it is a good idea to have more than one repository, for instance if you have two development groups that work on separate projects without sharing any code. All you have to do to have several repositories is to specify the appropriate repository, using the `CVSROOT' environment variable, the `-d' option to CVS, or (once you have checked out a working directory) by simply allowing CVS to use the repository that was used to check out the working directory (*note Specifying a repository::). The big advantage of having multiple repositories is that they can reside on different servers. With CVS version 1.10, a single command cannot recurse into directories from different repositories. With development versions of CVS, you can check out code from multiple servers into your working directory. CVS will recurse and handle all the details of making connections to as many server machines as necessary to perform the requested command. Here is an example of how to set up a working directory: cvs -d server1:/cvs co dir1 cd dir1 cvs -d server2:/root co sdir cvs update The `cvs co' commands set up the working directory, and then the `cvs update' command will contact server2, to update the dir1/sdir subdirectory, and server1, to update everything else. File: cvs.info, Node: Creating a repository, Next: Backing up, Prev: Multiple repositories, Up: Repository Creating a repository ===================== To set up a CVS repository, first choose the machine and disk on which you want to store the revision history of the source files. CPU and memory requirements are modest, so most machines should be adequate. For details see *Note Server requirements::. To estimate disk space requirements, if you are importing RCS files from another system, the size of those files is the approximate initial size of your repository, or if you are starting without any version history, a rule of thumb is to allow for the server approximately three times the size of the code to be under CVS for the repository (you will eventually outgrow this, but not for a while). On the machines on which the developers will be working, you'll want disk space for approximately one working directory for each developer (either the entire tree or a portion of it, depending on what each developer uses). The repository should be accessible (directly or via a networked file system) from all machines which want to use CVS in server or local mode; the client machines need not have any access to it other than via the CVS protocol. It is not possible to use CVS to read from a repository which one only has read access to; CVS needs to be able to create lock files (*note Concurrency::). To create a repository, run the `cvs init' command. It will set up an empty repository in the CVS root specified in the usual way (*note Repository::). For example, cvs -d /usr/local/cvsroot init `cvs init' is careful to never overwrite any existing files in the repository, so no harm is done if you run `cvs init' on an already set-up repository. `cvs init' will enable history logging; if you don't want that, remove the history file after running `cvs init'. *Note history file::. File: cvs.info, Node: Backing up, Next: Moving a repository, Prev: Creating a repository, Up: Repository Backing up a repository ======================= There is nothing particularly magical about the files in the repository; for the most part it is possible to back them up just like any other files. However, there are a few issues to consider. The first is that to be paranoid, one should either not use CVS during the backup, or have the backup program lock CVS while doing the backup. To not use CVS, you might forbid logins to machines which can access the repository, turn off your CVS server, or similar mechanisms. The details would depend on your operating system and how you have CVS set up. To lock CVS, you would create `#cvs.rfl' locks in each repository directory. See *Note Concurrency::, for more on CVS locks. Having said all this, if you just back up without any of these precautions, the results are unlikely to be particularly dire. Restoring from backup, the repository might be in an inconsistent state, but this would not be particularly hard to fix manually. When you restore a repository from backup, assuming that changes in the repository were made after the time of the backup, working directories which were not affected by the failure may refer to revisions which no longer exist in the repository. Trying to run CVS in such directories will typically produce an error message. One way to get those changes back into the repository is as follows: * Get a new working directory. * Copy the files from the working directory from before the failure over to the new working directory (do not copy the contents of the `CVS' directories, of course). * Working in the new working directory, use commands such as `cvs update' and `cvs diff' to figure out what has changed, and then when you are ready, commit the changes into the repository. File: cvs.info, Node: Moving a repository, Next: Remote repositories, Prev: Backing up, Up: Repository Moving a repository =================== Just as backing up the files in the repository is pretty much like backing up any other files, if you need to move a repository from one place to another it is also pretty much like just moving any other collection of files. The main thing to consider is that working directories point to the repository. The simplest way to deal with a moved repository is to just get a fresh working directory after the move. Of course, you'll want to make sure that the old working directory had been checked in before the move, or you figured out some other way to make sure that you don't lose any changes. If you really do want to reuse the existing working directory, it should be possible with manual surgery on the `CVS/Repository' files. You can see *Note Working directory storage::, for information on the `CVS/Repository' and `CVS/Root' files, but unless you are sure you want to bother, it probably isn't worth it. File: cvs.info, Node: Remote repositories, Next: Read-only access, Prev: Moving a repository, Up: Repository Remote repositories =================== Your working copy of the sources can be on a different machine than the repository. Using CVS in this manner is known as "client/server" operation. You run CVS on a machine which can mount your working directory, known as the "client", and tell it to communicate to a machine which can mount the repository, known as the "server". Generally, using a remote repository is just like using a local one, except that the format of the repository name is: :METHOD:[[USER][:PASSWORD]@]HOSTNAME[:[PORT]]/path/to/repository Specifying a password in the repository name is not recommended during checkout, since this will cause CVS to store a cleartext copy of the password in each created directory. `cvs login' first instead (*note Password authentication client::). The details of exactly what needs to be set up depend on how you are connecting to the server. If METHOD is not specified, and the repository name contains `:', then the default is `ext' or `server', depending on your platform; both are described in *Note Connecting via rsh::. * Menu: * Server requirements:: Memory and other resources for servers * Connecting via rsh:: Using the `rsh' program to connect * Password authenticated:: Direct connections using passwords * GSSAPI authenticated:: Direct connections using GSSAPI * Kerberos authenticated:: Direct connections with kerberos * Connecting via fork:: Using a forked `cvs server' to connect File: cvs.info, Node: Server requirements, Next: Connecting via rsh, Up: Remote repositories Server requirements ------------------- The quick answer to what sort of machine is suitable as a server is that requirements are modest--a server with 32M of memory or even less can handle a fairly large source tree with a fair amount of activity. The real answer, of course, is more complicated. Estimating the known areas of large memory consumption should be sufficient to estimate memory requirements. There are two such areas documented here; other memory consumption should be small by comparison (if you find that is not the case, let us know, as described in *Note BUGS::, so we can update this documentation). The first area of big memory consumption is large checkouts, when using the CVS server. The server consists of two processes for each client that it is serving. Memory consumption on the child process should remain fairly small. Memory consumption on the parent process, particularly if the network connection to the client is slow, can be expected to grow to slightly more than the size of the sources in a single directory, or two megabytes, whichever is larger. Multiplying the size of each CVS server by the number of servers which you expect to have active at one time should give an idea of memory requirements for the server. For the most part, the memory consumed by the parent process probably can be swap space rather than physical memory. The second area of large memory consumption is `diff', when checking in large files. This is required even for binary files. The rule of thumb is to allow about ten times the size of the largest file you will want to check in, although five times may be adequate. For example, if you want to check in a file which is 10 megabytes, you should have 100 megabytes of memory on the machine doing the checkin (the server machine for client/server, or the machine running CVS for non-client/server). This can be swap space rather than physical memory. Because the memory is only required briefly, there is no particular need to allow memory for more than one such checkin at a time. Resource consumption for the client is even more modest--any machine with enough capacity to run the operating system in question should have little trouble. For information on disk space requirements, see *Note Creating a repository::. File: cvs.info, Node: Connecting via rsh, Next: Password authenticated, Prev: Server requirements, Up: Remote repositories Connecting with rsh ------------------- CVS uses the `rsh' protocol to perform these operations, so the remote user host needs to have a `.rhosts' file which grants access to the local user. For example, suppose you are the user `mozart' on the local machine `toe.example.com', and the server machine is `faun.example.org'. On faun, put the following line into the file `.rhosts' in `bach''s home directory: toe.example.com mozart Then test that `rsh' is working with rsh -l bach faun.example.org 'echo $PATH' Next you have to make sure that `rsh' will be able to find the server. Make sure that the path which `rsh' printed in the above example includes the directory containing a program named `cvs' which is the server. You need to set the path in `.bashrc', `.cshrc', etc., not `.login' or `.profile'. Alternately, you can set the environment variable `CVS_SERVER' on the client machine to the filename of the server you want to use, for example `/usr/local/bin/cvs-1.6'. There is no need to edit `inetd.conf' or start a CVS server daemon. There are two access methods that you use in `CVSROOT' for rsh. `:server:' specifies an internal rsh client, which is supported only by some CVS ports. `:ext:' specifies an external rsh program. By default this is `rsh' but you may set the `CVS_RSH' environment variable to invoke another program which can access the remote server (for example, `remsh' on HP-UX 9 because `rsh' is something different). It must be a program which can transmit data to and from the server without modifying it; for example the Windows NT `rsh' is not suitable since it by default translates between CRLF and LF. The OS/2 CVS port has a hack to pass `-b' to `rsh' to get around this, but since this could potentially cause problems for programs other than the standard `rsh', it may change in the future. If you set `CVS_RSH' to `SSH' or some other rsh replacement, the instructions in the rest of this section concerning `.rhosts' and so on are likely to be inapplicable; consult the documentation for your rsh replacement. Continuing our example, supposing you want to access the module `foo' in the repository `/usr/local/cvsroot/', on machine `faun.example.org', you are ready to go: cvs -d :ext:bach@faun.example.org/usr/local/cvsroot checkout foo (The `bach@' can be omitted if the username is the same on both the local and remote hosts.) File: cvs.info, Node: Password authenticated, Next: GSSAPI authenticated, Prev: Connecting via rsh, Up: Remote repositories Direct connection with password authentication ---------------------------------------------- The CVS client can also connect to the server using a password protocol. This is particularly useful if using `rsh' is not feasible (for example, the server is behind a firewall), and Kerberos also is not available. To use this method, it is necessary to make some adjustments on both the server and client sides. * Menu: * Password authentication server:: Setting up the server * Password authentication client:: Using the client * Password authentication security:: What this method does and does not do File: cvs.info, Node: Password authentication server, Next: Password authentication client, Up: Password authenticated Setting up the server for password authentication ................................................. First of all, you probably want to tighten the permissions on the `$CVSROOT' and `$CVSROOT/CVSROOT' directories. See *Note Password authentication security::, for more details. On the server side, the file `/etc/inetd.conf' needs to be edited so `inetd' knows to run the command `cvs pserver' when it receives a connection on the right port. By default, the port number is 2401; it would be different if your client were compiled with `CVS_AUTH_PORT' defined to something else, though. This can also be sepcified in the CVSROOT variable (*note Remote repositories::) or overridden with the CVS_CLIENT_PORT environment variable (*note Environment variables::). If your `inetd' allows raw port numbers in `/etc/inetd.conf', then the following (all on a single line in `inetd.conf') should be sufficient: 2401 stream tcp nowait root /usr/local/bin/cvs cvs -f --allow-root=/usr/cvsroot pserver You could also use the `-T' option to specify a temporary directory. The `--allow-root' option specifies the allowable CVSROOT directory. Clients which attempt to use a different CVSROOT directory will not be allowed to connect. If there is more than one CVSROOT directory which you want to allow, repeat the option. (Unfortunately, many versions of `inetd' have very small limits on the number of arguments and/or the total length of the command. The usual solution to this problem is to have `inetd' run a shell script which then invokes CVS with the necessary arguments.) If your `inetd' wants a symbolic service name instead of a raw port number, then put this in `/etc/services': cvspserver 2401/tcp and put `cvspserver' instead of `2401' in `inetd.conf'. Once the above is taken care of, restart your `inetd', or do whatever is necessary to force it to reread its initialization files. If you are having trouble setting this up, see *Note Connection::. Because the client stores and transmits passwords in cleartext (almost--see *Note Password authentication security::, for details), a separate CVS password file is generally used, so people don't compromise their regular passwords when they access the repository. This file is `$CVSROOT/CVSROOT/passwd' (*note Intro administrative files::). It uses a colon-separated format, similar to `/etc/passwd' on Unix systems, except that it has fewer fields: CVS username, optional password, and an optional system username for CVS to run as if authentication succeeds. Here is an example `passwd' file with five entries: anonymous: bach:ULtgRLXo7NRxs spwang:1sOp854gDF3DY melissa:tGX1fS8sun6rY:pubcvs qproj:XR4EZcEs0szik:pubcvs (The passwords are encrypted according to the standard Unix `crypt()' function, so it is possible to paste in passwords directly from regular Unix `/etc/passwd' files.) The first line in the example will grant access to any CVS client attempting to authenticate as user `anonymous', no matter what password they use, including an empty password. (This is typical for sites granting anonymous read-only access; for information on how to do the "read-only" part, see *Note Read-only access::.) The second and third lines will grant access to `bach' and `spwang' if they supply their respective plaintext passwords. The fourth line will grant access to `melissa', if she supplies the correct password, but her CVS operations will actually run on the server side under the system user `pubcvs'. Thus, there need not be any system user named `melissa', but there _must_ be one named `pubcvs'. The fifth line shows that system user identities can be shared: any client who successfully authenticates as `qproj' will actually run as `pubcvs', just as `melissa' does. That way you could create a single, shared system user for each project in your repository, and give each developer their own line in the `$CVSROOT/CVSROOT/passwd' file. The CVS username on each line would be different, but the system username would be the same. The reason to have different CVS usernames is that CVS will log their actions under those names: when `melissa' commits a change to a project, the checkin is recorded in the project's history under the name `melissa', not `pubcvs'. And the reason to have them share a system username is so that you can arrange permissions in the relevant area of the repository such that only that account has write-permission there. If the system-user field is present, all password-authenticated CVS commands run as that user; if no system user is specified, CVS simply takes the CVS username as the system username and runs commands as that user. In either case, if there is no such user on the system, then the CVS operation will fail (regardless of whether the client supplied a valid password). The password and system-user fields can both be omitted (and if the system-user field is omitted, then also omit the colon that would have separated it from the encrypted password). For example, this would be a valid `$CVSROOT/CVSROOT/passwd' file: anonymous::pubcvs fish:rKa5jzULzmhOo:kfogel sussman:1sOp854gDF3DY When the password field is omitted or empty, then the client's authentication attempt will succeed with any password, including the empty string. However, the colon after the CVS username is always necessary, even if the password is empty. CVS can also fall back to use system authentication. When authenticating a password, the server first checks for the user in the `$CVSROOT/CVSROOT/passwd' file. If it finds the user, it will use that entry for authentication as described above. But if it does not find the user, or if the CVS `passwd' file does not exist, then the server can try to authenticate the username and password using the operating system's user-lookup routines (this "fallback" behavior can be disabled by setting `SystemAuth=no' in the CVS `config' file, *note config::). Be aware, however, that falling back to system authentication might be a security risk: CVS operations would then be authenticated with that user's regular login password, and the password flies across the network in plaintext. See *Note Password authentication security:: for more on this. Right now, the only way to put a password in the CVS `passwd' file is to paste it there from somewhere else. Someday, there may be a `cvs passwd' command. Unlike many of the files in `$CVSROOT/CVSROOT', it is normal to edit the `passwd' file in-place, rather than via CVS. This is because of the possible security risks of having the `passwd' file checked out to people's working copies. If you do want to include the `passwd' file in checkouts of `$CVSROOT/CVSROOT', see *Note checkoutlist::. File: cvs.info, Node: Password authentication client, Next: Password authentication security, Prev: Password authentication server, Up: Password authenticated Using the client with password authentication ............................................. To run a CVS command on a remote repository via the password-authenticating server, one specifies the `pserver' protocol, optional username, repository host, an optional port number, and path to the repository. For example: cvs -d :pserver:faun.example.org:/usr/local/cvsroot checkout someproj or CVSROOT=:pserver:bach@faun.example.org:2401/usr/local/cvsroot cvs checkout someproj However, unless you're connecting to a public-access repository (i.e., one where that username doesn't require a password), you'll need to supply a password or "log in" first. Logging in verifies your password with the repository and stores it in a file. It's done with the `login' command, which will prompt you interactively for the password if you didn't supply one as part of $CVSROOT: cvs -d :pserver:bach@faun.example.org:/usr/local/cvsroot login CVS password: or cvs -d :pserver:bach:p4ss30rd@faun.example.org:/usr/local/cvsroot login After you enter the password, CVS verifies it with the server. If the verification succeeds, then that combination of username, host, repository, and password is permanently recorded, so future transactions with that repository won't require you to run `cvs login'. (If verification fails, CVS will exit complaining that the password was incorrect, and nothing will be recorded.) The records are stored, by default, in the file `$HOME/.cvspass'. That file's format is human-readable, and to a degree human-editable, but note that the passwords are not stored in cleartext--they are trivially encoded to protect them from "innocent" compromise (i.e., inadvertent viewing by a system administrator or other non-malicious person). You can change the default location of this file by setting the `CVS_PASSFILE' environment variable. If you use this variable, make sure you set it _before_ `cvs login' is run. If you were to set it after running `cvs login', then later CVS commands would be unable to look up the password for transmission to the server. Once you have logged in, all CVS commands using that remote repository and username will authenticate with the stored password. So, for example cvs -d :pserver:bach@faun.example.org:/usr/local/cvsroot checkout foo should just work (unless the password changes on the server side, in which case you'll have to re-run `cvs login'). Note that if the `:pserver:' were not present in the repository specification, CVS would assume it should use `rsh' to connect with the server instead (*note Connecting via rsh::). Of course, once you have a working copy checked out and are running CVS commands from within it, there is no longer any need to specify the repository explicitly, because CVS can deduce the repository from the working copy's `CVS' subdirectory. The password for a given remote repository can be removed from the `CVS_PASSFILE' by using the `cvs logout' command. File: cvs.info, Node: Password authentication security, Prev: Password authentication client, Up: Password authenticated Security considerations with password authentication .................................................... The passwords are stored on the client side in a trivial encoding of the cleartext, and transmitted in the same encoding. The encoding is done only to prevent inadvertent password compromises (i.e., a system administrator accidentally looking at the file), and will not prevent even a naive attacker from gaining the password. The separate CVS password file (*note Password authentication server::) allows people to use a different password for repository access than for login access. On the other hand, once a user has non-read-only access to the repository, she can execute programs on the server system through a variety of means. Thus, repository access implies fairly broad system access as well. It might be possible to modify CVS to prevent that, but no one has done so as of this writing. Note that because the `$CVSROOT/CVSROOT' directory contains `passwd' and other files which are used to check security, you must control the permissions on this directory as tightly as the permissions on `/etc'. The same applies to the `$CVSROOT' directory itself and any directory above it in the tree. Anyone who has write access to such a directory will have the ability to become any user on the system. Note that these permissions are typically tighter than you would use if you are not using pserver. In summary, anyone who gets the password gets repository access (which may imply some measure of general system access as well). The password is available to anyone who can sniff network packets or read a protected (i.e., user read-only) file. If you want real security, get Kerberos. File: cvs.info, Node: GSSAPI authenticated, Next: Kerberos authenticated, Prev: Password authenticated, Up: Remote repositories Direct connection with GSSAPI ----------------------------- GSSAPI is a generic interface to network security systems such as Kerberos 5. If you have a working GSSAPI library, you can have CVS connect via a direct TCP connection, authenticating with GSSAPI. To do this, CVS needs to be compiled with GSSAPI support; when configuring CVS it tries to detect whether GSSAPI libraries using kerberos version 5 are present. You can also use the `--with-gssapi' flag to configure. The connection is authenticated using GSSAPI, but the message stream is _not_ authenticated by default. You must use the `-a' global option to request stream authentication. The data transmitted is _not_ encrypted by default. Encryption support must be compiled into both the client and the server; use the `--enable-encrypt' configure option to turn it on. You must then use the `-x' global option to request encryption. GSSAPI connections are handled on the server side by the same server which handles the password authentication server; see *Note Password authentication server::. If you are using a GSSAPI mechanism such as Kerberos which provides for strong authentication, you will probably want to disable the ability to authenticate via cleartext passwords. To do so, create an empty `CVSROOT/passwd' password file, and set `SystemAuth=no' in the config file (*note config::). The GSSAPI server uses a principal name of cvs/HOSTNAME, where HOSTNAME is the canonical name of the server host. You will have to set this up as required by your GSSAPI mechanism. To connect using GSSAPI, use `:gserver:'. For example, cvs -d :gserver:faun.example.org:/usr/local/cvsroot checkout foo File: cvs.info, Node: Kerberos authenticated, Next: Connecting via fork, Prev: GSSAPI authenticated, Up: Remote repositories Direct connection with kerberos ------------------------------- The easiest way to use kerberos is to use the kerberos `rsh', as described in *Note Connecting via rsh::. The main disadvantage of using rsh is that all the data needs to pass through additional programs, so it may be slower. So if you have kerberos installed you can connect via a direct TCP connection, authenticating with kerberos. This section concerns the kerberos network security system, version 4. Kerberos version 5 is supported via the GSSAPI generic network security interface, as described in the previous section. To do this, CVS needs to be compiled with kerberos support; when configuring CVS it tries to detect whether kerberos is present or you can use the `--with-krb4' flag to configure. The data transmitted is _not_ encrypted by default. Encryption support must be compiled into both the client and server; use the `--enable-encryption' configure option to turn it on. You must then use the `-x' global option to request encryption. You need to edit `inetd.conf' on the server machine to run `cvs kserver'. The client uses port 1999 by default; if you want to use another port specify it in the `CVSROOT' (*note Remote repositories::) or the `CVS_CLIENT_PORT' environment variable on the client. When you want to use CVS, get a ticket in the usual way (generally `kinit'); it must be a ticket which allows you to log into the server machine. Then you are ready to go: cvs -d :kserver:faun.example.org:/usr/local/cvsroot checkout foo Previous versions of CVS would fall back to a connection via rsh; this version will not do so. File: cvs.info, Node: Connecting via fork, Prev: Kerberos authenticated, Up: Remote repositories Connecting with fork -------------------- This access method allows you to connect to a repository on your local disk via the remote protocol. In other words it does pretty much the same thing as `:local:', but various quirks, bugs and the like are those of the remote CVS rather than the local CVS. For day-to-day operations you might prefer either `:local:' or `:fork:', depending on your preferences. Of course `:fork:' comes in particularly handy in testing or debugging `cvs' and the remote protocol. Specifically, we avoid all of the network-related setup/configuration, timeouts, and authentication inherent in the other remote access methods but still create a connection which uses the remote protocol. To connect using the `fork' method, use `:fork:' and the pathname to your local repository. For example: cvs -d :fork:/usr/local/cvsroot checkout foo As with `:ext:', the server is called `cvs' by default, or the value of the `CVS_SERVER' environment variable. File: cvs.info, Node: Read-only access, Next: Server temporary directory, Prev: Remote repositories, Up: Repository Read-only repository access =========================== It is possible to grant read-only repository access to people using the password-authenticated server (*note Password authenticated::). (The other access methods do not have explicit support for read-only users because those methods all assume login access to the repository machine anyway, and therefore the user can do whatever local file permissions allow her to do.) A user who has read-only access can do only those CVS operations which do not modify the repository, except for certain "administrative" files (such as lock files and the history file). It may be desirable to use this feature in conjunction with user-aliasing (*note Password authentication server::). Unlike with previous versions of CVS, read-only users should be able merely to read the repository, and not to execute programs on the server or otherwise gain unexpected levels of access. Or to be more accurate, the _known_ holes have been plugged. Because this feature is new and has not received a comprehensive security audit, you should use whatever level of caution seems warranted given your attitude concerning security. There are two ways to specify read-only access for a user: by inclusion, and by exclusion. "Inclusion" means listing that user specifically in the `$CVSROOT/CVSROOT/readers' file, which is simply a newline-separated list of users. Here is a sample `readers' file: melissa splotnik jrandom (Don't forget the newline after the last user.) "Exclusion" means explicitly listing everyone who has _write_ access--if the file $CVSROOT/CVSROOT/writers exists, then only those users listed in it have write access, and everyone else has read-only access (of course, even the read-only users still need to be listed in the CVS `passwd' file). The `writers' file has the same format as the `readers' file. Note: if your CVS `passwd' file maps cvs users onto system users (*note Password authentication server::), make sure you deny or grant read-only access using the _cvs_ usernames, not the system usernames. That is, the `readers' and `writers' files contain cvs usernames, which may or may not be the same as system usernames. Here is a complete description of the server's behavior in deciding whether to grant read-only or read-write access: If `readers' exists, and this user is listed in it, then she gets read-only access. Or if `writers' exists, and this user is NOT listed in it, then she also gets read-only access (this is true even if `readers' exists but she is not listed there). Otherwise, she gets full read-write access. Of course there is a conflict if the user is listed in both files. This is resolved in the more conservative way, it being better to protect the repository too much than too little: such a user gets read-only access. File: cvs.info, Node: Server temporary directory, Prev: Read-only access, Up: Repository Temporary directories for the server ==================================== While running, the CVS server creates temporary directories. They are named cvs-servPID where PID is the process identification number of the server. They are located in the directory specified by the `TMPDIR' environment variable (*note Environment variables::), the `-T' global option (*note Global options::), or failing that `/tmp'. In most cases the server will remove the temporary directory when it is done, whether it finishes normally or abnormally. However, there are a few cases in which the server does not or cannot remove the temporary directory, for example: * If the server aborts due to an internal server error, it may preserve the directory to aid in debugging * If the server is killed in a way that it has no way of cleaning up (most notably, `kill -KILL' on unix). * If the system shuts down without an orderly shutdown, which tells the server to clean up. In cases such as this, you will need to manually remove the `cvs-servPID' directories. As long as there is no server running with process identification number PID, it is safe to do so. File: cvs.info, Node: Starting a new project, Next: Revisions, Prev: Repository, Up: Top Starting a project with CVS *************************** Because renaming files and moving them between directories is somewhat inconvenient, the first thing you do when you start a new project should be to think through your file organization. It is not impossible to rename or move files, but it does increase the potential for confusion and CVS does have some quirks particularly in the area of renaming directories. *Note Moving files::. What to do next depends on the situation at hand. * Menu: * Setting up the files:: Getting the files into the repository * Defining the module:: How to make a module of the files File: cvs.info, Node: Setting up the files, Next: Defining the module, Up: Starting a new project Setting up the files ==================== The first step is to create the files inside the repository. This can be done in a couple of different ways. * Menu: * From files:: This method is useful with old projects where files already exists. * From other version control systems:: Old projects where you want to preserve history from another system. * From scratch:: Creating a directory tree from scratch. File: cvs.info, Node: From files, Next: From other version control systems, Up: Setting up the files Creating a directory tree from a number of files ------------------------------------------------ When you begin using CVS, you will probably already have several projects that can be put under CVS control. In these cases the easiest way is to use the `import' command. An example is probably the easiest way to explain how to use it. If the files you want to install in CVS reside in `WDIR', and you want them to appear in the repository as `$CVSROOT/yoyodyne/RDIR', you can do this: $ cd WDIR $ cvs import -m "Imported sources" yoyodyne/RDIR yoyo start Unless you supply a log message with the `-m' flag, CVS starts an editor and prompts for a message. The string `yoyo' is a "vendor tag", and `start' is a "release tag". They may fill no purpose in this context, but since CVS requires them they must be present. *Note Tracking sources::, for more information about them. You can now verify that it worked, and remove your original source directory. $ cd .. $ cvs checkout yoyodyne/RDIR # Explanation below $ diff -r WDIR yoyodyne/RDIR $ rm -r WDIR Erasing the original sources is a good idea, to make sure that you do not accidentally edit them in WDIR, bypassing CVS. Of course, it would be wise to make sure that you have a backup of the sources before you remove them. The `checkout' command can either take a module name as argument (as it has done in all previous examples) or a path name relative to `$CVSROOT', as it did in the example above. It is a good idea to check that the permissions CVS sets on the directories inside `$CVSROOT' are reasonable, and that they belong to the proper groups. *Note File permissions::. If some of the files you want to import are binary, you may want to use the wrappers features to specify which files are binary and which are not. *Note Wrappers::. File: cvs.info, Node: From other version control systems, Next: From scratch, Prev: From files, Up: Setting up the files Creating Files From Other Version Control Systems ------------------------------------------------- If you have a project which you are maintaining with another version control system, such as RCS, you may wish to put the files from that project into CVS, and preserve the revision history of the files. From RCS If you have been using RCS, find the RCS files--usually a file named `foo.c' will have its RCS file in `RCS/foo.c,v' (but it could be other places; consult the RCS documentation for details). Then create the appropriate directories in CVS if they do not already exist. Then copy the files into the appropriate directories in the CVS repository (the name in the repository must be the name of the source file with `,v' added; the files go directly in the appropriate directory of the repository, not in an `RCS' subdirectory). This is one of the few times when it is a good idea to access the CVS repository directly, rather than using CVS commands. Then you are ready to check out a new working directory. The RCS file should not be locked when you move it into CVS; if it is, CVS will have trouble letting you operate on it. From another version control system Many version control systems have the ability to export RCS files in the standard format. If yours does, export the RCS files and then follow the above instructions. Failing that, probably your best bet is to write a script that will check out the files one revision at a time using the command line interface to the other system, and then check the revisions into CVS. The `sccs2rcs' script mentioned below may be a useful example to follow. From SCCS There is a script in the `contrib' directory of the CVS source distribution called `sccs2rcs' which converts SCCS files to RCS files. Note: you must run it on a machine which has both SCCS and RCS installed, and like everything else in contrib it is unsupported (your mileage may vary). From PVCS There is a script in the `contrib' directory of the CVS source distribution called `pvcs_to_rcs' which converts PVCS archives to RCS files. You must run it on a machine which has both PVCS and RCS installed, and like everything else in contrib it is unsupported (your mileage may vary). See the comments in the script for details. File: cvs.info, Node: From scratch, Prev: From other version control systems, Up: Setting up the files Creating a directory tree from scratch -------------------------------------- For a new project, the easiest thing to do is probably to create an empty directory structure, like this: $ mkdir tc $ mkdir tc/man $ mkdir tc/testing After that, you use the `import' command to create the corresponding (empty) directory structure inside the repository: $ cd tc $ cvs import -m "Created directory structure" yoyodyne/DIR yoyo start Then, use `add' to add files (and new directories) as they appear. Check that the permissions CVS sets on the directories inside `$CVSROOT' are reasonable. File: cvs.info, Node: Defining the module, Prev: Setting up the files, Up: Starting a new project Defining the module =================== The next step is to define the module in the `modules' file. This is not strictly necessary, but modules can be convenient in grouping together related files and directories. In simple cases these steps are sufficient to define a module. 1. Get a working copy of the modules file. $ cvs checkout CVSROOT/modules $ cd CVSROOT 2. Edit the file and insert a line that defines the module. *Note Intro administrative files::, for an introduction. *Note modules::, for a full description of the modules file. You can use the following line to define the module `tc': tc yoyodyne/tc 3. Commit your changes to the modules file. $ cvs commit -m "Added the tc module." modules 4. Release the modules module. $ cd .. $ cvs release -d CVSROOT File: cvs.info, Node: Revisions, Next: Branching and merging, Prev: Starting a new project, Up: Top Revisions ********* For many uses of CVS, one doesn't need to worry too much about revision numbers; CVS assigns numbers such as `1.1', `1.2', and so on, and that is all one needs to know. However, some people prefer to have more knowledge and control concerning how CVS assigns revision numbers. If one wants to keep track of a set of revisions involving more than one file, such as which revisions went into a particular release, one uses a "tag", which is a symbolic revision which can be assigned to a numeric revision in each file. * Menu: * Revision numbers:: The meaning of a revision number * Versions revisions releases:: Terminology used in this manual * Assigning revisions:: Assigning revisions * Tags:: Tags--Symbolic revisions * Tagging the working directory:: The cvs tag command * Tagging by date/tag:: The cvs rtag command * Modifying tags:: Adding, renaming, and deleting tags * Tagging add/remove:: Tags with adding and removing files * Sticky tags:: Certain tags are persistent File: cvs.info, Node: Revision numbers, Next: Versions revisions releases, Up: Revisions Revision numbers ================ Each version of a file has a unique "revision number". Revision numbers look like `1.1', `1.2', `1.3.2.2' or even `1.3.2.2.4.5'. A revision number always has an even number of period-separated decimal integers. By default revision 1.1 is the first revision of a file. Each successive revision is given a new number by increasing the rightmost number by one. The following figure displays a few revisions, with newer revisions to the right. +-----+ +-----+ +-----+ +-----+ +-----+ ! 1.1 !----! 1.2 !----! 1.3 !----! 1.4 !----! 1.5 ! +-----+ +-----+ +-----+ +-----+ +-----+ It is also possible to end up with numbers containing more than one period, for example `1.3.2.2'. Such revisions represent revisions on branches (*note Branching and merging::); such revision numbers are explained in detail in *Note Branches and revisions::. File: cvs.info, Node: Versions revisions releases, Next: Assigning revisions, Prev: Revision numbers, Up: Revisions Versions, revisions and releases ================================ A file can have several versions, as described above. Likewise, a software product can have several versions. A software product is often given a version number such as `4.1.1'. Versions in the first sense are called "revisions" in this document, and versions in the second sense are called "releases". To avoid confusion, the word "version" is almost never used in this document. File: cvs.info, Node: Assigning revisions, Next: Tags, Prev: Versions revisions releases, Up: Revisions Assigning revisions =================== By default, CVS will assign numeric revisions by leaving the first number the same and incrementing the second number. For example, `1.1', `1.2', `1.3', etc. When adding a new file, the second number will always be one and the first number will equal the highest first number of any file in that directory. For example, the current directory contains files whose highest numbered revisions are `1.7', `3.1', and `4.12', then an added file will be given the numeric revision `4.1'. Normally there is no reason to care about the revision numbers--it is easier to treat them as internal numbers that CVS maintains, and tags provide a better way to distinguish between things like release 1 versus release 2 of your product (*note Tags::). However, if you want to set the numeric revisions, the `-r' option to `cvs commit' can do that. The `-r' option implies the `-f' option, in the sense that it causes the files to be committed even if they are not modified. For example, to bring all your files up to revision 3.0 (including those that haven't changed), you might invoke: $ cvs commit -r 3.0 Note that the number you specify with `-r' must be larger than any existing revision number. That is, if revision 3.0 exists, you cannot `cvs commit -r 1.3'. If you want to maintain several releases in parallel, you need to use a branch (*note Branching and merging::).