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.
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:
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.
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.