Version Control with

Subversion

What is Version Control Good For?

Maintaining project/file history - so you dont

have to worry about it

Managing collaboration on files and projects - so

multiple developers can work on the same set of
files

Managing releases - so you know what files are

in what version

Version Control Systems

Version control system keeps track of all work and all changes in
a set of files, typically the implementation of a software project,
and allows several (potentially widely-separated) developers to
collaborate.

Classification and examples:

Distributed model - each developer works directly with their own local

repository, and changes are shared between repositories

as a separate step
Open-source: GNU arch, Bazaar
Proprietary: BitKeeper, Code co-op, TeamWare

Client-server model - developers use a shared single repository

Local only: Revision Control System (RCS)

Open-source:CVS, CVSNT, OpenCVS, Subversion, Vesta
Proprietary: a lot

CVS

The most famous and popular open source version control

system is CVS (Concurrent Versions System)
It was invented and developed by Dick Grune in the 1980s
Latest release: 1.11.22 / 2006-06-09
Overview:
Client-server architecture
The Repository (server): The magic place that holds all
versions of everything
Working Copy (client): The place where you get to do
whatever you want
The CVS program manages moving files between the two

Subversion (SVN)

Goal: functional replacement for CVS

Started in early 2000 (by CollabNet)
Current version: 1.4.5 / 2007-08-27
More than just a replacement for CVS:

File and directory metadata

Faster network access
Requires less network access

Fundamental Concepts
The Repository

Subversion is a centralized system for sharing information

At its core is a repository, which is a central store of data

Can be accessed via a HTTP or HTTPS connection

Repository remembers every change

ever written to it:
every change to every file,
and even changes to the directory
tree itself, such as the addition,
deletion, and rearrangement of files
and directories.

Fundamental Concepts
Working Copy

A Subversion working copy is an ordinary

directory tree on local system, containing a
collection of files
Subversion provides commands to commit your
changes and merge other people changes into
your working copy
Each working directory has a .svn directory
(administrative directory)

Repository password are stored in each .svn folder

Stores a original copy of each file in directory

Basic Subversion Work Flow

Get a working copy

Make changes in your copy
Test them locally
Integrate them with any changes made to the
Repository
Commit them back to the Repository
Repeat these steps until a release is ready
Tag the release
Start making changes again for next release

How to start

Subversion client is distributed as command-line tool and

can be downloaded at:
http://subversion.tigris.org

Another one choice - Tortoise SVN, a Subversion client,

implemented as a windows shell extension:
http://tortoisesvn.tigris.org/

For development more convenient is to use Subclipse plugin for Eclipse. Subclipse can be installed and updated from
within Eclipse:
http://subclipse.tigris.org/install.html

Create repository location

In Eclipse switch to SVN Repository Exploring perspective
and create new Repository Location:

Type repository URL, e.g.

http://java-eim.googlecode.com/svn/trunk/

Check-out the project

A check-out creates a local working copy from the
repository.
1.
2.
3.

Right-click on a module for check-out, choose Checkout option

Choose to check-out using e.g. New Project Wizard
Check-out e.g. as General Project

Make changes and commit

A commit (check-in) occurs when a copy of the changes made
to the working copy is written or merged into the repository.

3.

Switch to another perspective, for example, Java

View and modify files in your working copy
When finished and ready to commit certainly(!!!) synchronize with
repository, to avoid conflicting changes (probably somebody already
modified the same files)!!! Right click Team Synchronize with Repository

4.

To compare local and remote files double click on file

1.
2.

Resolving Conflicts

Once in a while, you will get a conflict when you update your files
from the repository
Subversion places conflict markersspecial strings of text which
delimit the sides of the conflict - into the file to demonstrate the
overlapping areas
For every conflicted file Subversion places three additional files in
directory:

<<<<<<< filename
your changes
=======
code merged
from repository
>>>>>>> revision

filename.ext.mine - your file as it existed in your working copy

before you updated your working copy - without conflict markers. This file
has your latest changes in it.
filename.ext.rOLDREV - the file that was the BASE revision before
you updated your working copy. It is the file that you checked out before
you made your latest edits.
filename.ext.rNEWREV - the file that your Subversion client just
received from the server when you updated your working copy. This file
corresponds to the HEAD revision of the repository.

Manually resolve a conflict, execute resolved command, commit

More Concepts and Features

Revisions
Tagging and branching
Metadata (properties)
Locking

History of changes [Team Show History]

Compare different revisions

Lock is a piece of metadata which grants exclusive access to

one user to change a file

Select two versions from history Compare

Directories are versioned items

Deletes and moves are recorded
Copy sources are remembered

Revisions

Each time the repository accepts a

commit, this creates a new state of
the file system tree, called a revision.

Revision numbers are global, rather than per-file

Unique identifier for a state of project

Allows to talk about revision 2524

Simple way to tag (next slide)

Each revision corresponds to a single commit

Contains author, log message, and date

Branches and Tags

Branch - a line of development that exists independently

of another line, yet still shares
a common history if you look
far enough back in time.

Subversion implements cheap copies branches are

simply copies of the main trunk

Tag is just a snapshot of a project in time.

Tags are copies which are never changed

Might not even be necessary if you simply record the global

revision number that built your product

Metadata

Any file or directory can store properties

Properties are name/value pairs
Some standard properties exist

svn:ignore
svn:mime-type
svn:eol-style

etc.

User-defined properties are allowed

Property values can be text or binary

Subversion Hosting

When you decided to use Subversion in your

project, then you will need a server where to
place your code

There are free hosting systems, for example

CVDDude, berlios.de

List of sites that offer Subversion hosting:

http://subversion.tigris.org/links.html#hosting

References

Subversion home
http://svn.subversion.com/

Book Version Control with Subversion

http://svnbook.red-bean.com/

Subclipse
http://subclipse.tigris.org/