Svn Basic Tutorial

SVN BASIC TUTORIAL

Formatvorlage des Untertitelmasters
Avoiding headaches ™
durch Klicken bearbeiten

Direct deploy

Developer 1 Staging Live


Designer 1 Staging Live


Removal of direct deploy





Why not to directly deploy
• Can’t check the status of the environment
• Race conditions (DEV1 and DEV2 work on a
same file => collisions)
• Can’t easily update the environment (full
replace of the entire working copy needed)

SVN
• Subversion (SVN) is a SCM (Software
Configuration Management) implementation
• It allows to track changes in files and
directories
• It allows concurrent development on the
same files
• It is centralized (one server)

SVN Interaction
Designer 2
Designer 1 Staging Server

Developer 2 Issue Tracker

Developer 1 SVN Server Production Server

SVN development cycle

Get last project status from SVN server

Send work to SVN server Develop/Design

Test

SVN development (in SVN terms)

svn update

svn commit edit files

Test

How it works

Will make some examples with TortoiseSVN and
the command line to explain SVN

Fetching an existing project

The «.svn» directory is used by subversion to keep track of changes in the current
directory tree.
Do not change it, copy it somewhere else or delete it!

Adding some files to the project

Deploy with SVN
When having SSH access to a server, deploying
and updating becomes as easy as:

$ ssh user@server.com
$ cd path/to/project
$ svn update
(Or "svn co" if the project is not yet deployed)

Merging and conflicts
In the following schema, two developers try to
commit changes to a same file:
echo ‘hello to’;
Developer 1 echo $username;

echo ‘hello world ’;
Developer 2 echo $_GET[‘username’];

RED = changed by developer

How merging works
When Developer 2 tries to commit, SVN will tell him
that his copy is outdated, he will have to update it

How merging works
Merging won’t cause any changes on the server, you will first
get all the changes locally, so that you can review them. Here’s
the result of this merge case:

We can then

$ svn commit -m "Merged changes of marco’s commit"

Merging workflow
svn commit

Developer verifies merge Can’t commit (outdated working copy)

svn tries to merge svn update

What if SVN can’t merge?
svn commit

SVN couldn’t merge
Can’t commit (outdated working copy)
????????

svn tries to merge svn update

SVN Conflicts
SVN conflicts happen when two developers act on a
same file in the same line:

echo ‘hello everybody’;

echo ‘goodbye everybody’;

RED = changed by developer

SVN Conflicts
• index.php is a merged view of the conflict:

•
• index.php.r8 is the version before the update
• index.php.r9 is the version as in SVN server
• index.php.mine is the version you had in your
directory before committing

SVN Conflicts
We can edit the files until all conflicts are solved,
then tell SVN it should accept our new working
copy:

SVN Conflicts
svn commit

Mark conflicts as resolved Can’t commit (outdated working copy)

Manually edit conflicts svn update

SVN couldn’t merge svn tries to merge

SVN branching
Main project

Next major version update
The main project and it’s features
Bugfix for a known bug
Keeps track of changes to be merged into the next major release of the software
New feature that has to be added
Work in progress to fix a known bug
Alternate version to show to the customer
A new feature that requires some work without being influenced b

A slightly different version of the site that t

This is actually how
git-flow by nvie.com
handles development,
but SVN could also use
it!

What is a branch?
In SVN terms, a branch is just a copy of a
current tree. Let’s create a branch to
develop an alternate layout for the site:
svn copy -m “creating green site dev branch”
svn://path/to/repo/trunk
svn://path/to/repo/branches/wide-layout

(in TortoiseSVN it is under “branch/tag” in
context menu)

Switching working copy
Given that you checked out:

svn://project/path/trunk

You can now switch to a branch by doing

svn switch svn://project/path/branches/red

and you will be working on that copy

Merging branches
Once completed developing on a branch, you may
want to merge changes back:

Merging branches

Like normal conflict merging!

First you switch to the branch you want
changes to be merged to:

$ svn switch svn://path/to/target/branch

Then you merge a set of revision from the
branch you developed on (here 25 to
latest):

$ svn merge -r25:HEAD svn://path/to/merged/branch

Then SVN will merge any conflicts or set
conflicted state and allow you to check
what happened. After fixing conflicts:

$ svn ci -m “merging changes from new-layout branch”

Tags
Tags are markers used for deployment,
mainly for major release versions:

Tags
Tags are copies, exactly like branches:

$ svn copy
-m “tagging version 1.1 of the project”
svn://path/to/project
svn://path/to/tags/1.1

Except that you NEVER commit on tags!

svn:externals
Externals are “links” to other repositories:

$ svn propset svn:externals
“css/common svn://company/common/css/files”
./

Externals are not part of the repository, they are
just fetched with the repository (useful for deploying
applications!)

Update your projects before working

Do not commit broken code/functionality!

(Test before committing if possible!)

Commit as soon as a piece of the
functionality is completed

Branch life should not be too long

Long living branches increase merge
conflicts!

This forces you to keep small units of work

Every commit should have a purpose.
Commits with no purpose to be avoided!

If possible, avoid multiple commits on
separate files being part of one functionality

Never commit generated code/data!

Generated code can produce dozens of useless commits,
conflicts and generally, headaches!

EVERY
COMMIT
MUST
HAVE
DESCRIPTION

Examples of BAD commit messages:

-
“Fixed bug”
-
“Updated”
-
“Saved work”
-
“Updating”
-
“Merging changes”
-
“Saving work of 10/3/2010”

Examples of GOOD commit messages:

-
“Adding CSS definitions needed to create a lightbox
overlay when focus is on the offers iframe”
-
“Fixed bug with session expiring after browser restart on
IE7”
-
“Updated the logo with the new colors provided”
-
“Adding interfaces for the new blog feature

The interfaces are still quite lightweight, but should be
refreshed in the next days”
-

If using an issue tracker (Jira, Trac,
Bugzilla, Redmine, etc.), write the
issue ID in the commit message:

«Fixed iframe width causing
scrollbars to appear when not
needed as of PRJ-123»

Update working copy

Build (test first)

If there’s errors, fix them first! (do not work on broken projects)

Develop

Test changes

Commit (with appropriate message)

Resolve conflicts immediately

Svn Basic Tutorial

More Related Content

What's hot

Viewers also liked

Similar to Svn Basic Tutorial

Recently uploaded

Svn Basic Tutorial

Editor's Notes