Subversion

Subversion
A Version Control Tool

Prof. David Bernstein
James Madison University

Computer Science Department

bernstdh@jmu.edu

Introduction

What is Subversion?
- A version control system
Important Feature:
- Centralized
- Each repository has a URL
Getting Started:
- Creating a Repository:
  - The responsibility of a system administrator
- Checking-Out an Existing Repository:
  - When a repository is checked-out for the first time, a local/working copy is created (that includes all files and directories/folders in the repository) and the local/working copy is associated with the URL (Command: svn checkout url path)

Creating a Respository

When:
- At the beginning of a project
How:
- svnadmin create path
An Important Detail:
- A repository can either use the file system to store data (with the option --fs-type fsfs) or or the Berkeley database (with the option --fs-type bdb) if it is available

Respository Structure

The Traditional Structure:
- trunk - the trunk contains the code that will appear in the next major release
- branches - a branch is a copy of the trunk that is used for active development
- tags - a tag is a "frozen" copy of the code that is not used for active development
Kinds of Branches:
- Platform Branches - made to port the code to a different platform
- Experimental Branches - made to try experimental technologies
- Bug-Fix Branches - made to correct a serious defect (that will later be merged back into the trunk)
Kinds of Tags:
- Release Tags - a copy of the code made at release-time
- Pre-Bug-Fix Tags - a copy of the code made to record its state before a major bug fix
- Post-Bug-Fix Tags - a copy of the code made to record its state after a major bug fix

Normal Work Cycle

Update:
- Each developer's local/working copy must include changes made by every other developer (Command: svn update)
Modifications/Additions:
- The developer makes modifications to the documents in the local/working copy and the system keeps track of which files have been changed
- Modifications can be "undone" (Command: svn revert)
- Files that are added to or deleted from the local/working copy must be manually added to the repository (Command: svn add|delete file)
Prior to Check-In/Commit:
- Since another developer may have made changes to the same files, prior to check-in the developer should update the "base" (Command: svn update) and then compare the base and working copy (e.g., using a diff utility)
- Any conflicts must be resolved and the different versions "marked as merged" (Command: svn resolve)
Check-In/Commit:
- After the developer eliminates any conflicts, the local/working copy is checked-in/committed (Command: svn commit)
- Each committed change is given a revision number; the developer must include a comment describing the changes

When to Commit?

An Observation:
- Each commit increases the revision number by 1 and has an associated comment
An Implication:
- Changes in a commit should be related so that the revision numbers and the comments provide useful information
An Answer to the Question:
- A developer should commit each time a substantial change is made that stands on its own, and all related files should be committed together

User Interfaces

Command-Line Interface:
- Accessed using svn (or svnadmin) from the command prompt
Graphical User Interface:
- Accessed using the context menu associated with individual files (e.g., using TortoiseSVN for MS-Windows, right-clicking on a file provides a list of commands)
Integrated Development Environment:
- Many IDEs support Subversion (perhaps through a plug-in)

Other Useful Commands

list:
- View the contents of a repository
status:
- Display the status of the working/local copy
diff:
- Shows the differences between the working/local copy and the version in the repository (though GUI-based tools are often easier to use)