ECE Subversion (SVN) Server
Maintained by Bernie Roehl, Eric Praetzel, and Derek Rayside.
- Command line:
sudo apt-get install subversion
- Mac: Available through Fink, MacPorts, and HomeBrew
- Eclipse: There are two options. Note that Eclipse plugins should usually
be installed by using the Eclipse Update Manager, and not by direct download.
These plugins can use either the native Subversion command line client, or use
the SVNKit pure Java client. We recommend SVNKit because it can be tricky to
get the plugin to talk to the native client properly. You have to configure the plugin
to use SVNKit after the plugin is installed. You do not have to make a separate
download of SVNKit (it is included with the plugin).
- Windows: TortoiseSVN
- Mac: svnX
- Working copy vs repository
- Tags and Branches
Workflow and Terminology
Different version control systems use different terminology and have
different workflows. For example, Git and Perforce differ from
With Subversion you will typically `checkout' only once, at
the begging of term.
Then each time you sit down to work you will `update' before
When you are done work for that session, or at any other time the
fancy strikes you, you will `commit' your changes.
There are a few reasons why you want to update at the
beginning of every work session.
First, if you have done work on another computer or in another working
copy, then update will pull those changes to your current
computer (assuming that you committed them from the other
Second, the course staff may periodically patch the files to make
changes to support future labs or to correct bugs.
- SVN (and CVS) use optimistic locking, whereas Perforce appears to
use pessimistic locking.
Some problems that we have observed students experiencing
- Failing to commit. While practices vary depending on the
organization and project you are working on, for school work a good
general practice is to commit at the end of every working session.
Committing your work is not the same as submitting it to be graded. We
won't grade it until after the deadline. Moreover, the whole point of
a version control system is that one can recall the state of the files
at any point in time. Why should you commit frequently? First, it
ensures that your files are backed up. Every term at least one
student's laptop will get broken, lost, or stolen. Losing hardware
shouldn't mean losing data. Second, having a record of your work in
progress makes it easier for the staff to help you if you run into any
academic trouble or need to ask for a special exception.
- Mutating the file system of your working copy directly.
Inside your working copy you should aways use
svn mv, and
svn rm instead of the plain
- Using sftp in combination with Subversion. One student
tried checking out on ecelinux and then using sftp to transfer the
files to his local machine. This doesn't work because most sftp
clients will ignore the Subversion metadata. If you want to get a
working copy on your own machine, just install a Subversion client on
your machine and check out there.
- Trying to use one working copy for multiple purposes.
It's ok to have multiple working copies on your machine. Disk space is
cheap. Don't try to save disk space by having one working copy that
you share between Eclipse and the command line.
- Using Eclipse without a Subversion plugin. There are two
Subversion plugins for Eclipse: Subclipse and Subversive. You need to
use at least one of them. Otherwise Eclipse won't understand the svn
metadata in your project folders, and this can lead you to
inadvertently delete all of your source code from the repository (we
have observed two students do this).
- Importing projects into Eclipse. Do not checkout a
working copy with some other tool (e.g., TortoiseSVN) and then import
that working copy into Eclipse. Instead, perform the checkout with
your Eclipse Subversion plugin. If you do the checkout externally and
then import the working copy into Eclipse, Eclipse may not recognize
that the project is managed by Subversion, which can cause you
headaches down the road (see previous point).
- Grant yourself read and write permission to your repository. By default nobody, not even you, has
access to the data in the repository. Edit the ~/svn_repository.access file and add two lines like this
at the bottom of it:
userid = rw
- Check out your repository, e.g.:
svn co /ecesvn.uwaterloo.ca/people/userid
- Create the top-level repository structure. See suggestions below.
Repository structure suggestion for individuals:
- projects/ — code you write
- papers/ — words you write
- bib/ — shared bibliography files
- style/ — shared style files
- template/ — template for a blank paper
Repository structure suggestion for courses:
We suggest that you make a top-level directory for each offering of a course so that future instructors
will have access to the old materials. This is helpful for new instructors.
- 2012a/ — first offering in 2012
- students/ — directories for individual students
- teams/ — directories for teams/groups of students
- notes/ — shared directory to distribute notes to students
- staff/ — private staff directory
- 2012b/ — second offering in 2012
You can grant read or write access to paths in your repository by
editing your permissions file (~/svn_repository.access).
For example, suppose you are
collaborating with some friends on projectX:
friend1 = rw
friend2 = rw
Defining Groups of Users
You can define your own groups of users at the top of your svn_repository.access file (just under the
automatically inserted header). This is particularly useful for teaching. For example, we might define the
following groups for the first offering of a course in 2012:
staff-2012a = drayside, broehl, epraetzel
students-2012a = vmontagh, m22ma, s26stewa
When you make an individual directory for each student in a course repository you'll probably want to create
permissions rules like this:
drayside = rw
If you are comfortable with Bash scripts you can copy/paste/modify the following script to make a rule
for each student:
# help message
if [ $# == 0 ] ; then
echo "There are two ways to run this script:"
echo "1. Specify a list of student userids on the command line."
echo " e.g.: ./generate-student-rules.sh vmontagh m22ma s26stewa"
echo "2. Specify a file name that contains a list of student userids."
echo " e.g.: ./generate-student-rules.sh students.txt"
# figure out where to get list of student ids from
if [ -f $1 ] ; then
# take student list from file
# take student list from command line
# generate the rules
# modify this part to specify the directory you are interested in
# and the student group name for this offering
for s in $students ; do
echo "$s = rw"
echo "@students-2012 = "
Some Subversion clients have a
that causes them to unnecessarily request read access to the root
of the repository. To work around this, simply grant everyone read access to the root of the
* = r
This rule in fact allows any user to read the entire repository, not just the root
directory of the repository. To prevent everyone from having access to everything, you
add a rule to each of the top-level directories that denies access:
Your svn_repository.access file contains a header that is maintained the ECE technical staff. This header
includes definitions for user groups such as:
- ece-faculty: ECE Faculty
- se-faculty: Faculty from other departments who teach SE courses
- nano-faculty: Faculty from other departments who teach NE courses
- lab-instructors: ECE Lab Instructors
We recommend that you use these groups to grant read access to other instructors. Suppose that we are setting
the permissions for the top-level directory for the first offering of a course in 2012, which we call 2012a.
Suppose further that we have defined groups staff-2012a and students-2012a that includes the staff and
students for this offering. The permissions on the top-level directory for this offering might look like:
@staff-2012a = rw
@students-2012a = r
@ece-faculty = r
@se-faculty = r
@nano-faculty = r
@lab-instructors = r
- ecesvn.uwaterloo.ca:~/svn_repository.access — repository permissions
- ecesvn.uwaterloo.ca:~/svn_repository/ — repository (only the sysadmin has direct
access to these files; everyone else, including you, must interact with them through an svn client)
Trouble-shooting: everyone is denied access to everything
If you have a typo in your rules then Subversion will deny access to everyone.