Version Control. Luka Milovanov

Luka Milovanov

[email protected]

• Configuration management is the management of system change to software products

– Version management: consistent scheme of version identification

– System building (assembling components into a system)

– Change management: configuration data base records information about changes and change requests

• System releases include executable code, data, configuration files and documentation

• CASE tools are available to support all CM

activities (stand-alone and integrated systems)

CASE Tools for Configuration

Management

• Versioning

– RCS (Revision Control System) – CVS (Concurrent Version Control) – Subversion

• Build

– Shell scripts, make, ant • Change Management

– Bug database, change tracking • Release Management

– Feature tracking, rpm (build packages)

• Configuration management = Version + Change + Build +Release – Rational ClearCase

Version Control

• Discipline of managing the evolution of software

• Key element for moving from “initial” (undefined process) to “repeatable” (project management) stages in software systems development

• Keep track of the evolution of software

– When was a change made? – Why was it made?

– What exactly was changed?

• Make it possible (easier) to try out new parts and revert bad changes

How?

• Usually by having special software that

aids in version control

• The software keeps different versions in

a repository

• The developer checks out the program

onto his computer

• This workspace acts as the place where

changes to the program can be made

• Finally, the changes are committed to the

repository

Repository

• A shared database for engineered artifacts • Avoids:

– Overwriting one developer's changes by someone else – Forgetting what changes were made in an earlier

version

• Advantages:

– Freeing developer's creativity since it's easy to revert back to any change if something went wrong

– Tracking and remembering any change

Repository, cont.

• Additional features

– Bug-tracking systems, patch managers, mailing lists

• Allows queries about configurations to be answered

– Who has a particular system version?

– What platform is required for a particular version?

– What versions are affected by a change to component X? – How many reported faults in version T?

• Operations

– Check out (import)

• Obtain an existing version of an item from the database

– Check in (commit)

• Add new version of an item into the database

– It is not possible to modify existing items in the database. You need to create a new version

Version Derivation Structure

The repository's filesystem

The repository

•Imagine an array of revision numbers, starting at 0, stretching from left to right

•Each revision number has a filesystem tree hanging below it

•¨Each tree is a “snapshot” of the way the repository looked after each commit.

Basic Operations

• Checkout

• Add a file (or directory, symlink etc..)

• Remove a file

• Rename a file

• Committing changes

Subversion

• A better CVS

• Centralized server

• Supports file renaming (unlike CVS)

• Changes are in fact atomic (unlike CVS)

• Supports arbitrary tagging of files using

named properties

– Example: the svn:ignore property of a directory tells which files to ignore (e.g. temporary object files)

SVN Revision Numbers

apply to entire trees, not individual files

• Each revision number selects an entire tree, a particular state of the repository after some

committed change

– Another way to think about it is that revision N represents the state of the repository filesystem after the Nth commit

– When a Subversion user talks about “revision 5 of foo.c”, they really mean “foo.c as it appears in revision 5.”

• Notice that in general, revisions N and M of a file do not necessarily differ!

Checkout

• svn checkout http://hera.cs.abo.fi:8080/lab1_2005/luka_course_project

checks out the Luka’s course assignment

• Every directory has a special .svn directory

containing metadata about the project

Basic Work Cycle

1. Update your working copy

– svn update 2. Make changes – svn add – svn delete – svn copy – svn move

3. Examine your changes

– svn status – svn diff – svn revert

4. Merge others' changes

– svn merge – svn resolved

5. Commit your changes

– svn commit

!

– svn update and svn commit

• Examining History

– svn log

• Shows you broad information: log messages attached to revisions, and which paths changed in each revision

– svn diff

• Shows you the specific details of how a file changed over time

– svn cat

• This is used to retrieve any file as it existed in a particular revision number and display it on your screen

– svn list

• Displays the files in a directory for any given revision

• Other Useful Commands

– svn cleanup

• If Subversion ever tells you that some part of your working copy is “locked”, then this is the command that you should run

– svn import

• a quick way to copy an unversioned tree of files into a repository, creating intermediate directories as necessary

When to Commit

• Preferably: One idea – One commit

• When substantial work has been made (your own computer's harddisk might not be backuped)

• Checkpointing the current code so you can try different additions

• Don't mix several different changes

– Harder to understand what parts of the change are connected

Tags

• Tags are explicitely named snapshots of the project.

• Useful for making an external release so that you remember exactly what you have shipped

– Tag your solutions (next slide)

– In general: bug reports from customers are then analyzed by checking out the specific tag

• In subversion, this is done by copying, e.g. “svn

Your Repository Layout In

Subversion

• Directories

– myproject

– myproject/trunk – for files and unit tests – myproject/solutionN – for the solutions

• Solutions: tag when done

– svn copy

http://[YOUR_REPOSITORY]/myproject/trunk \

http://[YOUR_REPOSITORY]/myproject/solution1 \ -m “Assignment 1 completed“

Subclipse, checkout from

repository

1

Subclipse, cont.

3 4