Sharing Files Among Project Group Members

Most people will prefer to work on the project as part of a group. This necessitates some kind of sharing of files. There is no single best way to do this. Several options are described below.

Regardless of how you decide to share files, you are responsible for ensuring that your work is protected, so that only those in your group can see it. To aid you in this, you will be able to register your group with us. When you do so, a UNIX group identifier of the form cs350_XXX, where XXX is a three digit number that is unique to your group, will be created.

If you are not familiar with UNIX file permissions and UNIX groups and group identifiers, you should read the overview of UNIX file access controls. It describes how to protect your files.

Method 1: Private Source Code Directories, Private Build Directories

OK, this is not really sharing. Each partner can install his/her own copy of Nachos, using install_nachos. Updates can be propagated using e-mail or some other mechanism. For example, if one person updates foo.c, she can send copies of the modified foo.c to her partners. Although this is easy to set up, the potential problems should be clear. You must somehow decide who is allowed to update which files, so that copies to not diverge. And you had better not forget to send changes to your partner(s).

Method 2: Shared Source Code Directories, Private Build Directories

The Nachos distribution consists of several source code directories and several build directories. It is possible to set things up so that everyone in a group will share a single set of source code directories, but each group member will have their own private copy of the build directories. This means source code changes made by one member of the group will be visible immediately to other members of the group - there is no need to transmit them by e-mail or some other mechanism. Each time the source code is changed, each group member will need to rebuild their private copy of Nachos (in a build directory) which will reflect the changes.

An alternative to this would be to share both the build directories and the source code directories. In other words, one partner would install a copy of Nachos, and the remaining partner(s) would share that copy. However, a peculiarity of gcc makes it difficult for several users to build Nachos in a shared directory. Private build directories avoid this problem.

If you wish to go this route, one member of the group should install Nachos as usual using install_nachos. The remaining members of the group should each run the share_nachos script. This script links to the source directories created when install_nachos was run, and creates private copies of the build directories. (You can also set these links up manually, if you prefer. Feel free to look at the share_nachos script, in ~cs350/bin to see what it is doing.)

The share_nachos script takes two parameters. The first is the full pathname of the directory in which the to-be-shared copy of Nachos was installed. (If you do not give the full pathname, share_nachos will not work properly.) The second is the name of the directory in which the new shared copy of Nachos is to go. This directory will be created in the directory in which you run share_nachos

For example, suppose that users iwithu and uwithme are partners. Suppose that they have been assigned group id 044, and that both have directories called cs350 under their home directories. One user, iwithu, would install Nachos using:

cd ~/cs350
install_nachos nachos
This would create a new directory called ~iwithu/cs350/nachos containing a fresh, complete copy of Nachos. After this was finished, uwithme would do:
cd ~/cs350
share_nachos ~iwithu/cs350/nachos mynachos
The call to share_nachos will create a shared copy of Nachos under ~uwithme/cs350/mynachos. The source code directories in this copy will be symbolic links to the source directories under ~iwithu/cs350/nachos, while the build directories under ~uwithme/cs350/mynachos will be separate, private copies of the build directories under ~iwithu/cs350/nachos.

Note that the share_nachos script also makes a copy of the code/test and coff2noff directories. These directories are both build directories and source directories. Since they are build directories, they are shared by copying, rather than linking. That way, both partners can make the coff2noff and test programs by running GNU make in that directory. However, since there will be two separate copies of the code/test directory, changes made to the source in one copy will not be visible in the other. Such changes will need to be propagated explicitly among the partners.

Method 3: Shared Repository, Private Copies

Another option is to have a central repository (in one partner's account) in which a master copy of all Nachos files is kept. Permissions on the master copy are set so that all partners can access it. Each partner can then create their own private working copy of Nachos in their own directory by copying the files from the shared repository. After changing some files, partners can then copy the changed files back into the repository. This is called a "check-in/check-out" model, since members of the group check files out from the repository, change them, and then check the new versions back in.

Tools like CVS are available to help manage the shared repository. CVS commands are used to check code out of the repository and check it back in. Checking code out creates a new, private copy of the code. CVS can maintain many old versions of the code very efficiently, allowing you to roll back to old versions when you're trying to track down or avoid a bug. CVS also supports conflict resolution to help with the problem of two partners attempting to check out and modify the same piece of code.

If you are not already familiar with CVS, this approach will require an initial investment of time on your part. However, if you can afford the investment, you may find that the payback down the road is substantial.