Using Subversion to Submit Work
This tutorial assumes you are using the command line. Whether you are using a Mac, Linux, or Windows,
I highly recommend using the command line. If you need extra help figuring this out or have never used the command line, e-mail Paul Bossi (bossi-at-uchicago.edu) 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 by 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 create a directory that you'll work in, such as with:
mkdir ooarch-work
and then
cd ooarch-work
Once you are in ooarch-work or whatever directory you will use to store your code, you
run the following command, after replacing "CNetID" with your CNetID and "Qtr" with the three letter quarter code ("spr" for Spring, "sum" for Summer, etc):
svn checkout https://phoenixforge.cs.uchicago.edu/svn/CNetID-mpcs51050-Qtr-14/
OR: svn co ... (svn co is identical to svn checkout)
From then 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. This directory is called your "SVN repository."
Commands
Use
svn add X
for each file X that you want place under SVN's control. Say you write your code in a file called lab1.c. Move the file to your checked-out folder (with name CNetID-mpcs51050-spr-14/). Then, run
svn add lab1.c
from the command line. Now, your file is under version control, and is part of your repository. Next, use
svn commit X
OR: svn ci X (identical to svn commit, ci means "check-in," for those who like ci/co)
on any file X that has already been added (as above) to push your version of file X to the repository. Every time you commit, you send the committed file to a server (in this case, Phoenixforge). If anyone else uses checkout on that respository, they will be given copies of all files that have been added and committed, using the most recently committed version. The server also keeps all old versions of your files and logs of the changes made by each commit. You can see these logs by typing
svn log -v
An annoying attribute of the commit command is that it will place you into your
default command line text editor without telling you why. The reason it does
this is to give you a chance to attach a message to the commit. You absolutely
should include in this message a description of the changes that come with the
commit, for recordkeeping on your and our parts. These messages are part of the
svn log output. If you want to change the default command line text
editor, you need to change the EDITOR environment variable. If that sounds
complicated, I suggest using the -m flag with the commit command as
follows:
svn commit -m "your commit message here" X
Use
svn update
to update all files controlled by SVN to their newest versions. If you checkout a copy of a repository in two separate folders, then add, modify, and commit files from one of the folders, you can use this command from within the other folder to update the files in it. This is the command we will be using to get your work: we will checkout every student's repository and then use the update command once an assignment's deadline has been reached. Then, we will be able to see the most recent version of your submitted assignment and grade it.
We will also place your grades in your SVN repositories. You can use the update command to obtain your grade files once we have committed them. We will notify you when this happens by e-mail.
To see if you have local uncommitted changes, use
svn status
or for more information,
svn status -uv
These list files that have uncommitted changes (marked "M" for modified files, "A" for files to be added, and "D" for files to be deleted), and
files that have not been added or committed (marked with a "?"), called
"untracked" files in SVN.
There are many, many other SVN commands. If you are interested in learning more, feel free to send me an e-mail or read one of the tutorials below.
Submitting MPCS51050 Work
Because svn commit is how you are handing in your work, be
careful with it. Its proper use is your responsibility. In particular:
- Place work for a certain Homework and Lab Deliverable assignments, and the project, into folders titled sanely.
Each Homework or Lab Deliverable (or the project) should be completely encapsulated
in its own folder named labX, where X is the number of the lab.
Within this folder, you can structure your file storage however you want (create subfolders, organize things to your pleasure et cetera). You are required to include a README text file within this folder that (at the very least) states the programming language that you used. It can also be used to explain how to run your code, especially if it's done in an esoteric way.
- If you haven't done an svn add and svn commit, it hasn't been handed in.
Use svn status to see uncommitted changes and untracked files.
Make sure that you have done an svn add on all the files you want to hand in.
- You can double check that the files you think you have handed in, have really been handed in.
Associated with every per-student subproject is a web-based view of the SVN repository:
https://phoenixforge.cs.uchicago.edu/projects/CNetID-mpcs51050-Qtr-14/repository,
but that URL won't actually work until you replace
CNetID with your CNetID and Qtr with the quarter code (see above).
Use this to confirm what the graders will see when they use an svn update to collect your files, and to make sure that you have
not submitted an empty ("0 Bytes") file by accident.
- Avoid accidentally changing files and running svn commit again, after the deadline.
The graders do not want to do detective work to see if some files were committed by the deadline,
but others were not. The time that matters for determining the lateness penalty is
the time (on the SVN server) of your last commit within a given assignment subdirectory.
You can prevent accidental late hand-ins
by not making any changes after your final svn commit; that
way there are no changes to commit.
- "What time is it on the SVN server?" you might ask, if you suspect that the SVN server's
clock is running fast, thus putting you at a disadvantage. You can figure this out, well before
the deadline. After a local modification to file X, you can do something like:
date
svn commit -m "time testing" X
svn log X
The top entry in the "svn log" output contains the SVN server's record of the commit time,
which you can compare to what your local computer reported via "date" just before the commit. This is just like the svn log commands above,
but brings up the logs for file X only.
Installing SVN
- Linux
If you are using Linux, you can install SVN from the command line:
sudo apt-get install svn
- Mac
Mac machines should already have SVN installed on them. If you don't have it, you can find it here: http://subversion.apache.org/packages.html. I suggest the Wandisco download link.
- Windows
If you are using Windows, the most popular SVN client is TortoiseSVN: http://tortoisesvn.tigris.org/,
but it does not by default install the svn command line described on this page.
TortoiseSVN integrates into Windows Explorer (the file browser), which can be quite nice, and provides other nice UI features,
but as stated above, we recommend that you simply use the command line svn client described on this page,
and for that, the simplest option is
Slik Subversion,
which is regularly updated and great when
you just want the same svn command you use on Mac or Linux.
Click below to get Slik SVN:
- Download Slik SVN Client - svn command line
Make sure to update your PATH environment variable after install.
Also make sure to use <svn ci -m "my check in message"> (or identically, svn commit -m ...)
when doing check-ins so that subversion doesn't try to find an editor on
your system to force you to enter a check-in message.
On Windows, there may be no suitable editor for it to find!
If you go the TortoiseSVN route, make sure you change the install options to include the command line tools as well.
For TortoiseSVN GUI equivalencies, the following pages almost completely correspond to the command-line information above:
The documentation for TortoiseSVN can be found here: http://tortoisesvn.net/docs/release/TortoiseSVN_en/index.html.
- Eclipse
Eclipse has a plug-in that integrates SVN called Subclipse: http://subclipse.tigris.org/. The installation guide can be found here: http://subclipse.tigris.org/install.html.
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.