Using Subversion to Submit Work

This tutorial assumes you are using the command line. Whether you are using a Mac, Linux, or Windows, we highly recommend using the command line. If you need extra help figuring this out or have never used the command line, e-mail the TAs for help; don't be shy!

Introduction

In this class, you will use Subversion (abbreviated SVN) to submit all of your work. We will be using PhoenixForge to manage the SVN repositories associated with the class. Your authentication on PhoenixForge, and the SVN commands that connect to PhoenixForge, will be via your University CNetID and its password. Read this entire document; it contains information about SVN itself, as well as instructions about how you will be using it to submit homework. The easiest way to set this up is to have the initial subversion "checkout" command create a new directory containing your entire, personal repository (or "repo"). Let's create such a directory and let's call it "mpcs51050-work", and make sure to replace the CNET ID in the url below:
cd ~
svn co https://phoenixforge.cs.uchicago.edu/svn/YourCNetIDHere-mpcs51050-spr-15 mpcs51050-work

Notice the URL above won't work as is, and also notice there is a deliberate space before "mpcs51050-work" above! The "co" is an abbreviation for "checkout."

When the above command succeeds, you now have your local copy of your entire subversion repo for this class and it has been placed into a new directory, named "mpcs51050-work." You can now do very simple commands inside this directory to submit your homework. You can also use this as your own version control system while tuning and improving your homework.

Next let's switch into the repo directory.

cd mpcs51050-work

You are now in the directory that locally represents your svn repo.

From this point on you really only need to know three or four SVN commands. You execute these commands from within the directory created by the svn checkout command above, or within subdirectories like "lab1" and "lab2" (or further subdirectories you create yourself).

Directory Structure

If you view the repo you pulled down above, you should see folders named "grades", "lab1", "lab2", etc. The "grades" folder will contain your grades, while the "lab" folders are where you will put your homework.

Commands

svn add

Use

svn add X
for each file X that you want to place under SVN's control. Say you want to write some code for homework 1 (or "lab1") and you want to put it into a file named lab1.c:
cd ~
cd mpcs51050-work
cd lab1
vim lab1.c
(...do some editing and save your changes...)
svn add lab1.c
svn ci -m "This is a first cut"
In the above sequence you created a file, added it to svn's "staging" area (svn add), and you then checked-in your changes, committing them to the repo with the descriptive message about the code is a "first cut."
A git note: be aware that there is no need to "stage" modified files in subversion as there is in git. When you do an "svn ci" command in a directory, it will automatically check in modified files. So svn add is only needed for new files and new directories.
The "ci" command means "check-in." You can also use svn commit instead of svn ci if you prefer that nomenclature. The -m argument means "message" and allows you to skip a prompt for a commit message which svn will otherwise force you to deal with. (Note that on Windows, this prompt can be a problem, which is another reason why it's better to put the message right into the -m argument as shown. See the install section below for more on that problem.)

You can also use

svn add *
to add everything in a directory, including all directories.

svn ci (or svn commit)

Use

svn ci -m "Put a descriptive message here"
to send all your current changes (including additions or even deletions) to the server. This is the most important command for you to know to actually submit your homework, and the time when this command succeeds is the time that counts for when your work is considered officially received. The command "svn commit" is exactly the same thing as "svn ci."

svn up

Use

svn up
to update all files on your machine with the latest changes from the server. This is particularly useful to see the latest grades you have in your "grades" directory. Also, if you checkout a copy of a repository on two separate machines, then add, modify, and commit files on one of the machines, you can use this command on the other machine to update the files with the new changes - even if you've also made changes on that same machine being updated. (Regarding such merging, Subversion will notify you if there are conflicts that it can't resolve, but most of the time this will "just work." This is due to the fact that in most cases the two sets of changes do not affect identical lines and when that's true SVN can mostly figure things out by itself. Of course if the same line has changes on the server and changes made by you, then there is no way around a manual merge, and SVN will put up an alert describing that it cannot resolve the changes and needs your help.)

You can also use,

svn up someDirectoryOrFile
to only perform the update on a single item.

svn mkdir

Use

svn mkdir myNewDirectory 
when you want the repo to have a new directory. The directory is created for you on your local filesystem.

You can also use

svn add myExistingDirectory 
to add a directory that already exists. This command is recursive and will add everything inside the directory. Note that if you use svn add * that will also add existing directories and files to a repo.

Just like with other commands that change things, the changes are only reflected on the server at your next check-in.

svn stat

To see if you have changes that have not been checked-in, use

svn stat
or for more information,
svn stat -uv
These commands ignore files that are identical on both your machine and the server. They only list files that have changes and files that have never been added or committed. Files with changes could be marked "M" for modified, "A" for newly added, "D" for deleted as well as a couple other less frequently seen types. Files that are not in the repo are marked with a question mark character ("?").
Another git note: It bears repeating that there is no need to "stage" modified files in subversion as there is in git. So files marked "M" in svn stat will automatically be updated on the server at the next check-in.

svn revert

Use

svn revert myFile
if you have a problem because you just used svn add and you see (via svn stat) that it added some junk or temporary files that you did not mean to add and you are catching this before doing your check-in. After running svn revert the file is removed from the "staging" area and will no longer be part of your next check-in. This is a very important command to fix things when you can see your check-in has some garbage in it, which frequently happens when you use recursive svn add commands.

svn del

Use

svn del myFile
to remove a file when the file has already been checked-in to the repository. For example, it could be a similar scenario to the "svn revert" described above, but where you accidentally checked the item in. You can use svn del to remove it, but note that Subversion never gets rid of history, so this is not a good way to fix a problem with accidentally checking-in an inappropriately large file. Such problems should be prevented before check-in, not after.

svn log

Use

svn log
to see a history of the commits (aka. check-ins) in the current directory.

Submitting Work

Because svn ci is how you are handing in your work, be careful with it. Its proper use is your responsibility. In particular:

Installing SVN

Further Reading

Here are some links to other (more detailed) SVN informationals:

This tutorial was adapted from Gordon Kindlmann's, which can be found here: http://people.cs.uchicago.edu/~glk/class/scivis/svn.html.