Version Control withSubversion

What is Version Control Good For?

• Maintaining project/file history - so you don’t 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:

• Directory versioning• Atomic commits• File and directory metadata• Faster network access• Requires less network access• Branching and tagging are cheap

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 plug-in for Eclipse. Subclipse can be installed and updated from within Eclipse:http://subclipse.tigris.org/install.html

Create repository locationIn 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 projectA check-out creates a local working copy from the repository.

1. Right-click on a module for check-out, choose “Checkout…” option

2. Choose to check-out using e.g. New Project Wizard

3. Check-out e.g. as General Project

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

1. Switch to another perspective, for example, “Java”

2. View and modify files in your working copy

3. 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

Resolving Conflicts • Once in a while, you will get a conflict when you update your files

from the repository• Subversion places conflict markers—special 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.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

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

More Concepts and Features• Revisions• Tagging and branching• Metadata (properties)• Locking

• Lock is a piece of metadata which grants exclusive access toone user to change a file

• History of changes [Team Show History]

• Compare different revisions• 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• Allows to talk about “revision 2524”

• Unique identifier for a state of project• 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/