Skip to main content.

Subversion Quick Start Guide for CS162

Subversion is "like CVS but better" (it solves many of the technical problems and annoyances with CVS). If you have any comments or issues please let us know.

Setting up a repository

Note that your Subversion repository name is different from the group name you declare on the Groups page. Please email your TA to setup your repository and if there are any changes to your group membership.

  1. One group member (ONLY!) should import the Nachos code into the repository. To do this, cd into the Nachos source directory and type svn import -m "initial import" https://isvn.eecs.berkeley.edu/cs162/REPO_NAME/nachos to import the Nachos files into your Subversion repository. Be sure to run these commands from the 'nachos' directory! Otherwise you will recursively import everything in the current directory into Subversion, which is probably not what you want.

    Since you just imported this code into the repository, you want to get rid of the original nachos directory, and work on the version you will check out in the next step. So, move the directory nachos out of the way: mv nachos nachos.old Only one member of each group should use these commands; all other members will skip this step and continue on.

Basic Subversion Usage (Command-Line)

Note: If you are familiar with CVS, Subversion's commands are very similar and you should have no trouble at all.

  1. First, check out a local copy of the Nachos code: svn co https://isvn.eecs.berkeley.edu/cs162/group1/nachos This will create a nachos directory with all of the Nachos code in it.

  2. Edit your local copy of the files.

  3. When you are ready to make your changes available to other members of your group, commit the changes back to the repository: svn commit This will start up an editor for you to enter a log entry describing your changes. It makes a lot of sense enter a descriptive entry of the changes you made -- this will make tracking changes a lot easier.

    Note that you cannot commit changes unless your local files are up to date: that is, that you have been editing the most recent copy. See the next step for details.

  4. For other users to see the changes, they need to do: svn update which will update their local files to be in sync with the repository.

    If there are conflicts (that is, someone else edited the same file while you were in the process of editing it), you will be notified at this point and given a chance to fix the conflict. You will not be able to do a commit until you resolve the conflict. In order to fix a conflict, you edit the conflicting file, which will contain new lines with both the old and new versions. Decide which version you want to keep (or merge them somehow).

    svn update and svn commit list all the files they touch preceded by a one-character code signifying the change. Here is a quick key to the code:

    • M The file is modified in your working directory.
    • U The file was brought up to date with respect to the repository.
    • G The file was merged with changes from the repository.
    • ? The file is in your working directory, but not in the repository.
    • C A conflict was detected while trying to merge your changes to file with changes from the source repository. Edit the file, by hand to fix up the changes. Look for the string "<<<<". When done, type svn resolved [filename].
    • A The file is scheduled to be added to the source repository at the next commit point.
    • R The file is scheduled to be removed from the source repository at the next commit point.
  5. To add a file or directory to the repository, just do: svn add filenames... After svn add you need to svn commit for the addition to take effect.

  6. To remove a file from the Subversion repository: svn rm filename svn commit

Troubleshooting

Other Subversion Features

You can check out copy of code as it looked at a given time: svn co -r '{2005-02-10}' nachos

Subversion does not have a separate tag namespace (as you may be used to in CVS). Instead, tree copies are efficient in time and space. If you have a good, working version of the code and want to tag it as such, you can do: svn cp https://isvn.eecs.berkeley.edu/cs162/group1/nachos https://isvn.eecs.berkeley.edu/cs162/group1/nachos-working1 Later, you can check out the exact version of that code: svn co svn://cube.cs.berkeley.edu/GROUP/nachos-working1 This is also useful for tagging each of your submissions.

You can also look at a 'diff' of changes from one version of the code to another: svn diff -r '{2004-07-17}' svn diff -r PREV foo.java Also, the svn log command will show you the log entries for each version of files in the tree, so you can eyeball the changes that were made over time.

Type svn help to get a lot more information on using this wonderful tool.

Downloading software

Caveats!

Generally it is best to only check in source files to the repository -- anything that can be generated (say, a Java .class file) should not be checked in, since it's redundant (and confusing if the generated .class files don't match up with the source files).