/export/cvswork # cvs working folder. Modules come and go often
# keep a local copy just to save bandwidth
/export/cvsarchive # my own local cvs archive. keep forever
/export/cvswork # cvs working folder. Modules come and go often
# keep a local copy just to save bandwidth
/export/cvsarchive # my own local cvs archive. keep forever
# grep cvs /etc/services cvspserver 2401/tcp # CVS client/server operations cvspserver 2401/udp # CVS client/server operations cvsup 5999/tcp CVSup # CVSup file transfer/John Polstra/FreeBSD cvsup 5999/udp CVSup # CVSup file transfer/John Polstra/FreeBSD
This identifies the port CVS server will use. In most Linux/Unix installations, this is already defined. Port 2401 is the commonly accepted default port for CVS use.
xsel -p > /etc/xinetd.d/cvspserver
service cvspserver
{
socket_type = stream
protocol = tcp
wait = no
user = root
passenv = PATH
server = /usr/bin/cvs
server_args = -f -l --allow-root=/export/cvs pserver
disable = no
}
If cvspserver is defined in '/etc/services', you can omit the port line.
That second parameter is a lowercase 'L', not a 1 or an uppercase 'i'.
The last parameter, '—allow-root=' defines the location of the repository to be used. There can be more than one, in which case each would have its own '—allow-root' parameter.
/etc/rc.d/init.d/xinetd restart
export CVS_RSH=ssh cd ~/work/CVSROOT cvs -d :ext:$USER@sunshine:/export/cvs status
Pick an empty directory to be your CVSROOT and set the `CVSROOT' environment variable to point there. The CVSROOT environment points to where the repository lives:
export CVSROOT=/export/cvs
Create the repository directory (with the project folder):
mkdir -p $CVSROOT/CVSROOT chown tomcat4:cvs -R $CVSROOT chmod ug+rwx,o-rwx -R $CVSROOT chown :cvs -R $CVSROOT/CVSROOT ls -ld $CVSROOT
Tell CVS to initialize the repository:
cvs init echo "*.class *.txt *.jar" > $CVSROOT/CVSROOT/cvsignore chown tomcat4:cvs !$ chmod 644 !$
chown :cvs -R $CVSROOT
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.
export CVSROOT=/export/cvs export CVSREAD=yes
cd /java/expresso/webapps
codesrc=expresso/WEB-INF/classes/com/ (cd $codesrc; cvs import -m "Imported sources" $codesrc gsc start)
codesrc=expresso/WEB-INF/config codesrc=expresso/WEB-INF/tld codesrc=expresso/expresso/jsp codesrc=expresso/expresso/style codesrc=expresso/foo
Unless you supply a log message with the `-m' flag, CVS starts an editor and prompts for a message. The string `gsc' 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.
Use `-I name' to specify file names that should be ignored during import. Or, export CVSIGNORE="*.class *.txt *.jar"
You MUST change directory to the source-code-directory and then do cvs import. Otherwise, when doing checkout it says module is unknown.
"nxt -ls" can't reflect the adding of the group
use 'su -' instead.
*References*: cvs.ps
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 com- mand. 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. See Chapter 13 [Tracking sources], page 79, 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. See Section 2.2.2 [File permis- sions], page 9.
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. See Section C.2 [Wrappers], page 132.
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 suffcient to define a module.
Get a working copy of the modules file.
$ cvs checkout CVSROOT/modules $ cd CVSROOT
Edit the file and insert a line that defines the module. See Section 2.4 [Intro adminis- trative files], page 16, for an introduction. See Section C.1 [modules], page 129, for a full description of the modules file. You can use the following line to define the module `tc':
tc yoyodyne/tc
Commit your changes to the modules file.
$ cvs commit -m "Added the tc module." modules
Release the modules module.
$ cd .. $ cvs release -d CVSROOT
It is possible to grant read-only repository access to people using the password- authenticated server (see Section 2.9.3 [Password authenticated], page 21). (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 (see Section 2.9.3.1 [Password authentication server], page 21).
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 (see Section 2.9.3.1 [Password authentication server], page 21), 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.
*References*: cvs.ps
First of all, you probably want to tighten the permissions on the `$CVSROOT' and `$CVSROOT/CVSROOT' directories. See Section 2.9.3.3 [Password authentication security], page 24, 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 (see Section 2.9 [Remote repositories], page 19) or overridden with the CVS CLIENT PORT environment variable (see Appendix D [Environment variables], page 143). If your inetd allows raw port numbers in `/etc/inetd.conf', then the following (all on a single line in `inetd.conf') should be suffcient:
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.
Because the client stores and transmits passwords in cleartext (almost|see Section 2.9.3.3 [Password authentication security], page 24, 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' (see Section 2.4 [Intro administrative files], page 16). 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 authenti- cate 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 Section 2.10 [Read-only access], page 26.)
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, see Section C.13 [config], page 141). 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 Section 2.9.3.3 [Password authentication security], page 24 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 Section C.10 [checkoutlist], page 139.
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 (see Section 2.9.2 [Connecting via rsh], page 20).
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.
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 (see Section 2.9.3.1 [Password authentication server], page 21) 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.
files under com/jcorporate/expresso/core/ are not imported into CVS.
Use the per directory controlling file: .cvsignore.
echo "! .cvsignore CVS" > /java/expresso/webapps/expresso/WEB-INF/classes/com/jcorporate/expresso/.cvsignore
Newsgroups: comp.software.config-mgmt Date: 2001-06-20 15:13:21 PST
I'm brand new to CVS, but have installed version 1.11.1p1 on RedHat 7.1. After initing the repository at /cvs/cvsroot I got all of the CVSROOT files OK. I have looked at section 3.1.3 ("Creating a directory tree from scratch") in the Cederqvist text, and I tried to do the same within my directory structure…
/cvs
\
+ cvsroot
\
+ CVSROOT
|
+ nms
\
+ eicore
\
+ src
The book says to:
create tc, and the empty subdirs man and testing
cd to tc
cvs import -m "Created…" yoyodyne/dir yoyo start
As root, and with CVSROOT=/cvs/cvsroot I did the following:
created eicore and the empty subdir src
cd to nms
cvs import -m "Created…" nms/eicore nms start
Regardless of whether I use nms/eicore, nms/src or nms as the argument I get the following error message:
"cvs [import aborted]: attempt to import the repository"
>I get the following error message: > "cvs [import aborted]: attempt to import the repository"
It sounds like you are in a directory within the repository, rather than in a working directory. i.e. a checked-out one, somewhere else. (It can be part of a checkout of the whole repository, or just a part.)
Erik
The repository is the complete tree starting from the position started with lower case written cvsroot. I think you should rename your directories into things like /Repository and do CVSROOT=/Repository after that an "cvs init". The basic Idea of CVS is to allow concurrent development. This means many users (e.g. you) can checkout a copy from the repository into their work area (usualy their home dirs).
After that you get the following tree:
/Repository CVSROOT
If you do "cvs import … XYZ BRANCH START" you get the following:
/Repository CVSROOT XYZ
Using of CVS should only be done as non root which means cvs co, cvs import etc. Administration of the Repository have to be done as root.
Karl Heinz Marbaise
http://groups.google.com/groups?hl=en&selm=qh8zmtugt8.fsf_-_%40ruckus.brouhaha.com
Newsgroups: alt.sys.pdp10 Date: 2001-02-26 16:12:04 PST
> Help! I tried to create my local repository but have some problems with > 'cvs import' command. [...] > $ cvs import -m "Initial TS10 Developement" ts10 >> > When I attempt to execute 'cvs import ...', I was kept getting > usage information instead! :-(
Don't use cvs import. below is detailed instructions on what to do.
Here's some step-by-step instructions to help you with CVS. It is easiest if you put your source directory into a nested directory (which need not contain anything else). I'm assuming you'll have it in the directory ~/work/ts10 but you can easily substitute anywhere else. I also assume that you are using the bash shell; if you use tcsh you'll have to use setenv instead of export. I've shown the shell prompt as '% '.
Set the CVSROOT environment variable to point to where you want the repository to live:
% export CVSROOT=~/ts10-cvs
For tcsh, the equivalent would be:
% setenv CVSROOT ~/ts10-cvs
(Note the space instead of the equals sign.)
Create the repository directory:
% mkdir $CVSROOT
Tell CVS to initialize the repository:
% cvs init
Create the subdirectory in the repository for your source files:
% mkdir $CVSROOT/ts10 % ls $CVSROOT CVSROOT ts10 %
If your working source tree has subdirectories, create a similar subdirectory structure here. For instance, if you have ts10/foo, ts10/bar, and ts10/bar/baz:
% mkdir $CVSROOT/ts10/foo $CVSROOT/ts10/bar $CVSROOT/ts10/bar/baz
cd to the parent of the source directory:
% cd ~/work
(Note that your ts10 source code is in the ts10 directory *below* this one. If you do an "ls" at this point, it should just show the ts10 subdirectory.)
Do a cvs checkout. This sets up the CVS subdirectories in the source tree:
% cvs checkout ts10
This will produce output with one line for each file in ts10, with a question mark at the left. This indicates that cvs has found those files but they are not yet part of the repository.
cd into the source directory:
% cd ts10
do a cvs add of all files you want to go into the repository, this tells CVS that you are going to check them in:
% cvs add README Makefile *.c *.h
(Include any other files you want in source control. If you want to leave some source or header files out that aren't actually part of your release, you can list the source files explicitly rather than using a wildcard.)
If you have subdirectories, cd into them and do a cvs add on them as well. cd back to the top (ts10) directory when you're done.
commit the files, this actually puts them into the repository:
% cvs commit -m "initial version"
The -m and string give the initial log message, use anything you feel appopriate. cvs commit works recursively, and will commit all the files you've added, even in subdirectories.
If you ever need to commit files individually, you can give the files on the command line. For instance, if you wanted foo.c and bar.c to have a different initial log message than the rest, then before doing a commit of everything (as above), you can do this:
% cvs commit -m "a different log message" foo.c bar.c
verify that everything looks good:
% cvs status | more
This will give details about every file in the repository. Each file should have a working revision and a repository revision of 1.1, and Status of Up-to-date. Sometimes I like a more concise summary with just the Status field:
% cvs status | grep Status
(note the upper case S on the Status in the grep)
For extra verification, check out a copy into a new directory and do a build. This will make sure you haven't accidentally omitted any files:
Make sure CVSROOT is set as in step 1 of the setup above:
% export CVSROOT=~/ts10-cvs
Make a new directory to check out into:
% mkdir ~/work2
cd into that directory
% cd ~/work2
check out the code:
% cvs checkout ts10
cd into ts10:
% cd ts10
build the code as usual:
% make
Once you've done that, you can blow away work2 if you like:
% cd ~ % rm -rf ~/work2
Package up the repository:
cd into the repository top-level directory:
% cd $CVSROOT
tar it up:
% tar -cvzf ~/ts10-cvs.tar.gz ./ts10
cd out:
% cd ~
If you like, email me the repository and I'll test it on my system to make sure there are no problems. However, if you've followed the steps above, I think it should be fine.
scp the file to SourceForge: scp ts10-cvs.tar.gz sword7@ts10.sourceforge.net:/
Submit a request to the Sourceforge CVS people to import the repository - for directions see http://sourceforge.net/docman/display_doc.php?docid=768&group_id=1
Let me know if you run into any trouble.
Best regards, Eric
Newsgroups: comp.software.config-mgmt Date: 2000/03/26
I just finished reading the 2 CVS books: free chapters of Open Source Development with CVS and Cederqvist. I am using ver 1.06 on intel win95 (One day I will switch over to Linux). I successfully did the following:
Created cvs repository. I used "cvs -d :local:e:/user/khunginit"
Imported a project into the repository.
Checked out the project.
Everything is fine except that I don't know how to tell CVS my user name and therefore after keyword expansion, the author (in one of my file) is anonymous.
Hmmm… Try setting an environment variable called LOGNAME to your userid, like this:
set LOGNAME=khung
Randy Rizun
v21.7, 2001-10-13
This document is a "practical guide" to very quickly setup CVS/RCS source code control system. This document has custom shell scripts that are wrappers on top of CVS. These scripts provide an easy user interface for CVS.
The above url has good directory structure, but the info is dated (v4.0, 15 November 1999).
Has the newiest version, better directory structure, but contents are enclosed in tables.