CPSC 329 Software Development Fall 2017

CPSC 329 Lab 3: More Subversive

This handout/tutorial continues the use of Subversive in developing software. (Installation of the plugin was covered in lab 1, and basic features in lab 2.) It is assumed that you have an understanding of the core concepts of version control, SVN terminology, and Eclipse terminology.

Important: Go carefully - make sure you understand the concepts of SVN and what the appropriate action is, and read (and verify) the contents of dialog boxes instead of just clicking ahead on auto-pilot. Version control systems are meant to not forget, which makes fixing problems of incorrect or undesired usage that much more difficult.


Successful completion of this lab means that you:

Note that achieving these objectives means that you understand what the steps you are carrying out accomplish and why you would do them - you can nominally complete the lab by just doing all the steps but you will have missed the point.


Work in pairs (and one group of three) to complete this lab. There is no limit on collaboration with others, but you need to make sure that you understand for yourself how (and why) to do things.

Due Date and Deliverables

due Tue Sep 19 at the start of class

One handin per group.

To hand in the lab, create a handin tag as directed and include the names of everyone in your group in the commit comment. The repository logs will be reviewed to determine that you carried out the rest of the lab correctly.


This lab continues with the dog door program you worked on in lab 2. If possible, team up with the same person you did lab 2 with.

Branching and Merging

So far there has only been one line of development (the trunk) - the project is initially shared to the trunk, then everyone checks out a working copy from the trunk and commits changes back to the trunk.

A branch allows for development along multiple lines at once, while still maintaining the ability to integrate changes from one branch into another. A branch is a copy of some subtree of the repository - within the repository - but isn't an independent copy. (SVN maintains information about when the branch was made and what it was a copy of. Also note that branches and working copies are different - a branch is another copy within the repository, while a working copy is a copy on your local computer.)

Two practical ways that branches can be used in software development are release branches and feature branches.

When using release branches, branches are created to allow for continued development of new features while a version is readied for release. It works like this:

When using feature branches, branches are created temporarily to allow a developer to work on a complex feature without interfering with the runnability of the trunk. It works like this:

The advantage of this scenario is that the developer can continue a habit of frequent commits without committing incomplete and potentially not-yet-working code to the trunk which will break everyone else's efforts the next time they update.

Merging refers to the process of copying changes from one branch to another. For release branches, bug fixes can be copied from trunk to branch (via cherrypicking in Subversive) or from branch to trunk (via an automatic reintegrate merge in Subversive). For feature branches, changes should periodically be copied from the trunk to the branch so the branch doesn't get too out of sync with the trunk (via an automatic sync merge in Subversive) and once from branch to trunk (via an automatic reintegrate merge in Subversive) when the work in the branch is complete.


Creating Branches

While you can create a branch from a revision in the repository or your working copy, it is recommended that you only do the former (copying a revision in the repository) as it is both more efficient and safer (in terms of avoiding unnecessary complications during merging) than branching from a working copy. It is also recommended that the working copy be up-to-date with the repository (no uncommitted local modifications).

It is recommended that you check that things worked as expected by browsing the repository - the new branch should be in a subdirectory with the branch name in the branches directory. (Don't forget to refresh the SVN Repositories view!) If it is not correct, delete the incorrect directory in the repository and try again.

Also verify that in the Package Explorer, the project is now linked to the trunk/branch that you want to work on. (If not, switch branches as described below.)

Note that while it is recommended that the working copy be up-to-date with some revision in the repository (typically the HEAD revision) before branching, there is a common scenario where this is not the case - if you have started making changes in your working copy and then realize that those changes should be in their own branch, you can create a new branch from the repository copy of the branch your working copy is linked to and then switch to the new branch. This will preserve your local modifications while ensuring that future commits go to the new branch rather than the old.

Switching Branches

Sometimes you need to work on a different branch (such as when you want to merge changes). You can check out a new working copy from the repository, or you can switch your current working copy to the correct branch. The latter is more efficient, and offers some more advanced options such as only switching part of the working copy (not addressed here).

Observe that the working copy is now linked to the new branch, and that the contents of the working copy have been updated to match the new branch. (If you don't have any local modifications in your working copy, switching is the equivalent to checking out a new working copy from the desired location.) Also check that the project structure is correct.

As with branching, it is recommended that the working copy be up-to-date with some revision in the repository (typically the HEAD revision) before the switch, but SVN will preserve any local modifications as needed (conflict resolution might be required).


"Merging" refers to copying changes from one branch to another. Since all merges have the potential for conflicts that must be resolved manually, the pattern is to merge from some branch into your working copy and then committing the changes once the merge is complete.

There are several different merging scenarios:

Only the first two will be addressed here; see chapter 4 of the SVN book (Version Control with Subversion) for information on the others.

Try It

Tired of having to operate the remote control every time Fido wants to go out or come in, you've decided to add a bark recognizer to the door so that it will open automatically when Fido wants to come back in. (You'll still use the remote to let Fido out - you don't want Fido leaving the house any time he wants!)

Use the idea of a feature branch to work on the bark recognizer without disturbing the working (non-bark-recognizer) version of the dog door:

But the bark recognizer opens the door for any dog, not just Fido. Let's add that enhancement...

Meanwhile, the customer has requested that if the bark recognizer doesn't open the door when Fido barks, they should be able to use the remote to open the door instead. This is an important update and can't wait until the enhanced bark recognizer is complete.

Now, finish enhancing the bark recognizer:

The new bark recognizer is now ready for inclusion in the trunk, but before you can do that, you should pull the changes from the trunk (using the remote if the bark recognizer doesn't open the door) into the branch:

Browsing History

If you want to examine the current (HEAD) revision, you can browse the repository in the SVN Repository Exploring perspective in Eclipse or in a web browser (point it to the repository's URL).

If you want to locate a particular change (e.g. for undo or cherrypicking merge operations) or browse an older revision, you can do this through either the Package Explorer in the Java perspective (if the file or directory you want to view is in your current working copy) or through the SVN Repositories view in the SVN Repository Exploring perspective (for any file or directory). In either case, right-click on the file, directory, or project name and choose Team->Show History... This will display the history for all of the changes in that subtree in the repository; you can browse through the revisions (see where the commit comments are important!), click on a revision to see the changes applied in that revision, and double-click on a file listed within a changeset to see its state at that revision.

You can also choose Team->Show Revision Graph... instead of Show History... - this gives you a graphical view the relationship of various branches to each other. Try right-clicking on a particular branch or file. If you don't have a large history, selecting "Show nodes for all revisions" in the "Show Revision Graph" dialog box can make for a more easily understood display.

Try It


Valid HTML 4.01!