Using CVS and Unix Groups to Share Files in your Team
This page is organized as follows:
- Unix Permissions and Groups
- CVS setup
- Working with CVS from the Shell
- Using CVS from Eclipse
- Troubleshooting
Unix Permissions and Groups
Basic Unix Permissions
The following describes the use of Unix permission groups on the department Linux machines (e.g., popeye). We recommend that you use these machines to share files and to host your group web site. It is worth emphasizing that to effectively share files, as described below, you have to get the files to the department machines. That is we are going to be explaining a "centralized" solution that uses the shared file system of the department Linux machines as a central server.
On Unix and Linux, which is a variant of Unix, the permissions of each file or directory are recorded for 3 categories of users: the user who owns the file, the group that owns the file, and all others. Within a one of these categories, the file system records 3 permissions; these are the ability to read, write, and execute the file. These are displayed by the ls command with the -l option. For example, consider the following.
$ ls -l *.java
-rw-rw-r-- 1 leavens jml 12093 May 13 10:42 Bug.java
-rw-rw-r-- 1 leavens jml 11915 Aug 12 10:32 Foo.java
-rw-r--r-- 1 leavens staff 731 Sep 16 22:34 JMLTestRunner.java
Note: In code examples, green text is program output, yellow bold text is user input, and cyan text is sample code.
The above example shows three files named *.java in the current directory. As shown in the 3rd column of output, all three files are owned by user leavens. As shown in the 4th column of output, The first two are owned by the group jml, and the last is owned by the group staff.
The first column of output gives the permissions for each file. The first file, Bug.java has permission -rw-rw-r--. In this string, the first position is a hyphen (-); this means that this line of output describes a file, not a directory; a directory would have a "d" in this position. Following the first position are three lists of permissions relating the the three categories of users, each of these consisting of 3 positions (rw-, rw-, and r--). The first list of 3 permissions (rw-) is for the user who owns the file, the second list of 3 permissions (also rw- for the first file) is for the group that owns the file, and the third (r--) is for others.
Within each list of 3 permissions, the first position tells whether the corresponding category of users has read permission. The category has read permission if there is an r in the output for that file and category of users. In our example, all three categories of users have read permission for all the files; that means, these files allow anyone to read them. A file with permission -rw-r----- however, would not be readable by others, and a file with permission ---------- would not be readable by anyone, even its owner. (Actually, on Unix, the superuser, root, is not subject to permissions, and can read such a file.)
Within each list of 3 permissions, the second position tells whether the corresponding category of users has read permission. The category has write permission if there is a w in the output for that file and category of users. In our example, other users have no permission to write the these files. Similarly the group owner jml has permission to write the first two files, but members of the staff group do not have permission to write the third file. The user who owns these files (leavens) has permission to write them all. A file with permission -r--r----- however, would not be writeable by its owner.
Within each list of 3 permissions, the third position tells whether the corresponding category of users has execute permission. The category has execute permission if there is an x in the output for that file and category of users. In our example, no users have permission to execute these files.
Execute premission is required to either run a file as a program or, for a directory, to allow the corresponding category of users to access named files and directories within the directory. For example, suppose your home directory is owned by group cs362a and has permissions drwxr-x--x. Then you, as the owner of your home directory, can read, write, and access files in it. In this case also the group owner, cs362a, can read and access it, but cannot write it. Further, other users can access it. Users who can access but not read your home directory can access files and subdirectories in it if they know (or can guess) their names. However, such users cannot poke around by using ls or wildcard patterns. This is because the ability to use ls to display names in a directory, or to use wildcards, requires both read and execute permissions. Thus, for example it may be useful to give your home directory a permission such as drwx--x--x, which allows other directory's group owner to access specific subdirectories (e.g., WWW and your CVS repository), but not to go hunting for other things.
Changing Group Ownership and Permissions
To change the group owner of a file, use the chgrp command. For example, the following changes the group owner of the file named Stack.java to cs362b. You must be the owner of a file to do this, and you must also have write permission in the directory containing the file.
$ chgrp cs362b Stack.java
To change the group owner of a directory, you can use the same command. If you want to also change the group owner of all the files, in a directory, use the chgrp -R command. For example, the following changes the group owner of the current directory and all of the files and directories it contains, recursively.
$ chgrp -R cs362c .
For more information, see the manual page for the chgrp command by executing man chgrp from a Linux machine's shell.
Changing Group Permissionsy
To change the permissions (mode) of a file, use the chmod command. For example, the following changes the permissions of the file Stack.java to make it readable and writeable by the group. You must be the owner of a file to do this, and you must also have write permission in the directory containing the file. Also, you should change the group owner of the file first.
$ chmod g+rw Stack.java
To change the permissions of a directory, you can use the same command. If you want to change both the permissions of the directory and all the files in it, recursively, use the chmod -R command. For example, the following changes the group owner of the current directory and all of the files and directories it contains, recursively.
$ chmod -R g+w .
For more information, see the manual page for the chmod command by executing man chmod from a Linux machine's shell. You may also want to use the find command. For example, the following is handy for changing only directories beneath the current directory to be readable, writeable, and executable by the group. (The input has to be on a single line, or the newline has to be escaped by using a backslash.)
$ find . -type d -exec chmod g+rwx '{}' ';'
Default permissions for new files
When you create a file in Unix, its permissions are based on your current umask value. The umask is a bit pattern such that the bits set in it deny corresponding permissions for various categories of users. Each umask consists of 9 bits, specified by 3 octal digits, the first digit is the mask for the user who owns the file, the second digit is the mask for the file's group owner, and the third is the mask for others. For example, the default umask on the department machines is 077, which means that no permissions are masked for the user (0), but all permissions are masked for the file's group and others.
For working in teams, it is useful to set your umask to 007, so that people in your team can (by default) read, write, and execute files and directories that you create. To do this execute the following command:
$ umask 027
You may want to put this in your ~/.profile (or ~/.login if you use csh or tcsh) file, so that it is executed every time you log in to a Com S machine. See the manual page for the umask command by executing man umask for more details.
[an error occurred while processing this directive]CVS Setup
The concurrent version control system (CVS) is a tool that can help track multiple versions of programs and other project artifacts. Refer to the online documentation for CVS for more about it. You should read at least the overview section.
To start your team needs to decide where to store your team's CVS repository. Perhaps the member of your team with the most free disk quota, or who has the most experience with Linux should be chosen for this. Then have that person log in to a department Linux machine (e.g., popeye). If this person's home directory is /home/thatperson, then you should follow the CVS documentation's directions for setting up the CVS repository.
$ umask 007
$ cd ~
$ cvs -d /home/thatperson/CVS-repository init
Then you should start a CVS project. You will be making a directory tree from scratch. For example (you may want to change Project into something more descriptive for your team's project):
$ cd ~
$ mkdir Project
$ cd Project
$ cvs -d /home/thatperson/CVS-repository import \
-m"creating directory structure" Project ignored start
No conflicts created by this import
This will create a directory Project under /home/thatperson/CVS-repository and make other entires in the repository for the project.
Finally, double check the file and directory permissions for the repository. You may need to do something like the following, if necessary, to correct permissions (change the Unix group to your actual group).
$ cd ~/CVS-repository
$ chgrp -R cs362f .
$ find . -type d -exec chmod g+rwx '{}' ';'
$ chmod -R g+rx CVS-repository
Your team needs to also make it possible to edit the team web site. You can use same kind of commands (see the Unix commands above) for making the WWW/cs362 directory for the course and the files it contains owned by your team's Unix group and writeable by it. (If you like, you can also put your web site's files under CVS control, by making a new project for them.)
[an error occurred while processing this directive]Working with CVS
To start using CVS, you should put the location of your team's CVS repository in the shell environment variable CVSROOT. You should also make sure your umask is set to grant people in your team's unix group premissions that are necessary. To do this, if you use bash (or sh) as your shell (which is the default on our Linux machines), put something like following lines in your .profile file:
export CVSROOT='/home/thatperson/CVS-repository'
umask 007
(Or if you use tcsh or csh as your shell, instead put something like the following in your .login file.)
setenv CVSROOT '/home/thatperson/CVS-repository'
umask 007
Then test your file by source-ing it, for example, for bash:
$ source .profile
The reason for the above test is to make sure you can still log in with the new .profile file.
Now to start using CVS, each person working on the project does a cvs checkout of the project. For example:
$ cd ~
$ cvs checkout -d -P Project
Then you can use the cvs add command to add files and directories to the repository.
$ cvs add NewFile.java
When you add directories, you should be sure to check the team CVS repository persmissions on the new directory, and make sure your team's group owns the directory, and that it has read, write, and execute permissions on it. This should happen automatically if you set up your umask properly. Still, you should double check the first few times.
When you finished adding files and directories, or when you have changes to give to others (e.g., when they pass your tests), use the cvs commit command to commit your changes.
$ cvs commit -m"A note saying why I made this change" ChangedFile.java
Your team members can then get your changes, if they want them, by executing the cvs update command. It's a good idea to send email to notify other team members that you have such a change that they may want to get. However, the beauty of CVS is that they don't have to use your changes right away, but can update whenever they want.
You should read the CVS documentation for more background and details.
[an error occurred while processing this directive]Using CVS from Eclipse
It's also possible to use CVS from inside Eclipse. This avoids using all of the Unix-level commands for CVS. From the "Window" menu, click on "Open Perspective", and then on the "CVS Repository Exploring" perspective. In the top row of icons, the 6th icon from the left is for "Create a new CVS Repository Location"; click on this icon, and fill in the form. Use "popeye.cs.iastate.edu" as the host, and give the full path to your team's repository. Consult the documentation for more details.
[an error occurred while processing this directive]Troubleshooting Problems
For now, look at the CVS documentation for help.
[an error occurred while processing this directive]Last modified Monday, August 2, 2004.
[an error occurred while processing this directive]