SVN – revision control – slides – pdf

SVN - revision control

Coordinating projects

Problem: How to coordinate and synchronize code

between multiple developers on a project?

– Work on the same computer, take turns coding


– Send files by e-mail or put them online. Lots of

manual work.

– Put files on a shared disk. Files get overwritten or

deleted. Lots of direct coordination.

– In short: Error prone and inefficient.

What is a version control system?

A repository of files with monitored

access to keep track of who and what

changes were made to files

Version tracking

Collaboration and sharing files

Historical information

Retrieve past versions

Manage branches

Why use it?

In code development, a version control

system is, at this point, almost mandatory

With multiple developers impossible to keep

track of versions with out it

Must be able to roll back a version if a test

suite fails

Must be able to tag software releases

Coordinating projects (solution)

Solution: A source code management (scm) tool.

– Repository: Code stored on a central server.

– Working copy: The developer checks out a copy

of the code in the repository to his/her computer.

– Revision history: Every change to every file is

logged in a database. Can be rollbacked.

– Conflict handling: What happens when two

developers change the same file? The same line?

Basic Work Cycle

Checkout a working copy

Update a working copy

Make changes

Examine your changes

Commit your changes

Some Commands

Subversion commands communicating with the server:

svn checkout …

svn commit

Offline Subversion commands:

svn add

svn delete

svn status     (high level compare)

svn diff    (low level compare)

svn rename

svn move

More information:

svn help [cmd]

Create Repository

Creating a repository:

/home/shafiqAlibhai> svnadmin create assignment1

…results in a repository directory:


What’s inside the repository?








Basic commands

svn checkout

$ svn checkout http://url/repos/projectA

A projectA/file1

A projectA/file2

A projectA/file3

Checked out revision 28.


svn status

$ svn status

M projectA/file1

?    projectA/file4


Basic commands

svn add/delete/copy/move

$ svn add file4

A file4


svn commit

$ svn commit –m “fix another bugs”

Sending         file1

Adding          file4

Transmitting file data.

Committed revision 29.


Basic commands

svn log

$ svn log

r29 | shafiq | Tue, 26 Dec 2006 18:03:46 +0900 | 1 line

fix another bugs

r28 | shafiq | Mon, 25 Dec 2006 13:01:24 +0900 | 1 line

Fixed some bugs.

r27 | jAlibhai | Mon, 25 Dec 2006 12:58:24 +0900 | 1 line

Some works.

Basic Commands

svn update

$ svn update

U file1

A file4

Updated to revision 29

$ svn update –r28

U file1

D file4

Updated to revision 28


Trunk, Branches, Tags

SVN project directories are structured by convention with three top-level



Represents the ‘main line’ of development with an entire copy of the



Contains subdirectories, each holding an entire copy of the project

Each branch constitutes a significant enhancement to the project that

can be worked on independently.


Contains subdirectories, each containing one snapshot of the project.

Each snapshot represents a “public release” or other archival

configuration of the project.

Trunk vs. Branch

Trunk represents the stable version of the

system. It should always work, without errors


Branches represent temporary development

streams to implement significant new features.

This allows commits to repository without breaking

the trunk (stable) version.

Branches may contain error/warnings etc.

Queries / Feedback