Introduction to Subversion

First, version control systems track the version of all the files in each repository, rather than individual files separately. Programming frequently involves making a set of changes to a group of files that together accomplish something—like fixing a bug or adding a new feature. So when you commit your work using Subversion, it remembers the state of all the files in your repository at that time. This allows you to compare what your project looked like at different times, and undo an entire set of changes that might have caused a problem.

Note that this also means that Subversion does not track all the changes you save to a file. Unless you commit your changes, they are not saved to your repository. This may seem like an annoyance—after all, systems like Dropbox will sync your files every time you save them.

But when programming this turns out to be a huge advantage. Let’s say you save a version of Foo.java to test—but it contains errors. Now if you are using Dropbox, everyone has that broken version of the file. But if you are using Subversion, you can test your code, notice the errors, and fix them before committing.

A Subversion 1 commit is really their equivalent of the save operation. Regardless of whether you save your files in Eclipse or any other way, you have to commit them to your repository before it will save and remember them.

Version control systems also allow you to add your own notes to each commit. This is called a comment. Comments should summarize what changes are included in the new version of the project. Good comments are extremely helpful to other developers that are trying to understand how the code is evolving. All version control systems have ways to view the list of version with their comments. This can be useful when you want to see how things have changed, or back up and use an older version of a project where some feature was working that isn’t any more.

Second, version control systems help you merge changes made by different developers—even to the same file. Say that Foo.java has 1000 lines. Alice makes a change at the top of the file. Concurrently, Bob makes a change to the bottom of the file. Systems like Dropbox will typically force you to address this conflict by choosing either Alice’s version of the file or Bob’s. But version control systems can frequently automatically merge non-overlapping changes to source code files—allowing you to choose to combine the changes from Alice with the changes from Bob. When you are working in large teams on large software projects, this capability is extremely handy.

All repositories for this semester are stored as subfolders under https://subversion.ews.illinois.edu/svn/fa17-cs125/. To get the URL for your repository, simply add your Illinois NetID. Here are a few examples:

Hopefully by now you get the pattern. Now that you have the link to your Subversion repository ready, let’s set up Eclipse to use it:

At this point you can view your repository. To see what it currently contains, right click on it and click "Refresh".

When you start a new project in Eclipse, the files are initially stored locally and not synchronized with your remote repository. To add a project to your repository and begin tracking changes using Subversion, follow the following steps:

Now you’ve figured out how to add things to your repository. But how do you retrieve stuff that is already there?

Subversion refers to this process as a checkout. To checkout a project in Eclipse, follow the following instructions:

Remember: version control systems only save the change you have made when you tell them to. This is called a commit, and the process called committing. Given that committing is essentially saving your changes, this have given rise to memes like the one on the right—although it refers to Git, another popular version control system.

Once you commit a version of a file, Subversion will remember its committed contents forever—even if you change or delete it. So you should get into the habit of committing early and often. Here are some good times to commit your code:

Get in the habit now of committing your code regularly. Version control systems are very efficient at storing commits, and so the overhead of performing them is small. Better to have things saved than to want desperately to get back to a previous version or remember how you did something and not have it committed.

Note that most version control systems will require you to tell them the first time you want to add a new file to a project. Once you do this once, that file will be tracked in the future—but there is an initial step that you may sometimes miss.

Here’s how to generate a Subversion commit using Eclipse:

Committing allows you to save your changes to the project in your repository. To retrieve updates made by others, you perform an update.

Subversion, like other version control systems, provides you with control over when you receive updates. This is another big advantage when compared with systems like Dropbox that propagate changes immediately. If you are working with others, you may not want to see their changes immediately—particularly if they might interfere with what you are working on. Having to update manually means that you get to choose a moment when you are ready to receive changes.

In CS 125 you are working on assignments independently—so you might ask, who else would be updating my repository? There are two possible answers to that question! First, we may use your Subversion repository to return grades and testing results to you. We do this by adding new files to your repository that you then retrieve the next time you update. It’s also possible that you may choose to work on two different machines—a laptop and a desktop at home. Assuming you have set up Eclipse and Subversion properly on both, you can use the update command on one machine to retrieve commits made on the other.

Here’s how you perform an update in Eclipse:

At this point it is possible that the changes made by others have conflicted with yours. If this happens, Eclipse will mark the files in your project for you to fix.

Version control systems are designed to allow you to compare between your local files and the copies that are available in the repository. So you should never browse the contents of your remote repository to make sure that its contents are up-to-date. Not only is that tedious, but it doesn’t work well once your repository has even just a few files.

Instead, use Subversion to examine the differences between your local files and your remote repository. Here’s how: