SVN Basic Tutorial 12040823s2813 Phpapp01

SVN BASIC TUTORIAL
Avoiding headaches
Direct deploy
Develop
er 1
Stagi
ng
Live
Develop
er 2
Stagi
ng
Live
Designe
r1
Stagi
ng
Live
Designe
r2
Stagi
ng
Live
Removal of direct deploy

Develop
er 1
Stagi
ng
Live
Develop
er 2
Stagi
ng
Live
Designe
r1
Stagi
ng
Live
Designe
r2
Stagi
ng
Live
Why not to directly deploy

Cant check the status of the
environment
Race conditions (DEV1 and DEV2
work on a same file => collisions)
Cant 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
1
Designer
2
Develop
er 2
Develop
er 1
Staging
Server
Issue
Tracker
SVN
Serv
er
Productio
n Server
SVN development cycle

Get last
project status
from SVN
server
Send work to
SVN server
Develop/Desi
gn
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

project

project

project

project
Updating working copy
Deploy with SVN

When having SSH access to a server,
deploying and updating becomes as easy
as:
$ ssh [email protected]
$ 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:
Develope
r1
Develope
r2
echo hello to;

echo $username;
echo hello world ;
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
How merging works

Merging wont cause any changes on the server,
you will first get all the changes locally, so that
you can review them. Heres the result of this
merge case:
We can then
$ svn commit -m "Merged changes of
marcos commit"
Merging workflow
svn commit
Developer
verifies
merge
svn tries to
merge
Cant
commit
(outdated
working
copy)
svn update
What if SVN cant merge?

svn commit
SVN
couldnt
merge
????????
svn tries to
merge
Cant
commit
(outdated
working
copy)
svn update
SVN Conflicts
SVN conflicts happen when two developers
act on a same file in the same line:
Develope
r1
Develope
r2
echo hello
everybody;
echo
$_GET[username];
goodbye
echo
everybody;
echo
$_GET[username];
RED = changed by developer
SVN Conflicts
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
Cant
commit
(outdated
working
copy)
Manuall
y edit
conflicts
svn update
SVN
couldnt
merge
svn tries to
merge
Parallel development
SVN branching
Main project
The main project
and its features
Next major version update

Keeps track of
changes to be
merged into the
next major
release of the
software
Bugfix for a known bug

Work in progress
to fix a known
bug
New feature that has to be

added
Alternate
version to show
A new feature
to the customer
that requires
some work
A slightly
without being
different version
influenced by
of the site that
other bugfixes
the customer has
and changes
requested, but
that isnt ready
yet, and could be
discarded
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. Lets 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 newlayout 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!)
Best practices
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
(yes, multiline commits are allowed!)
If using an issue tracker

(Jira, Trac, Bugzilla,
Redmine, etc.), write the
issue ID in the commit
message:
Fixed iframe width causing
Optimal process
Update working copy

Build (test first)
If theres errors, fix them first! (do not work on broken
projects)
Develop
Test changes
Commit (with appropriate message)
Resolve conflicts immediately
Suggested
Workflow
This is actually
how
git-flow by
nvie.com handles
development, but
SVN could also
use it!

SVN Basic Tutorial 12040823s2813 Phpapp01

Uploaded by

Copyright:

Available Formats

SVN Basic Tutorial 12040823s2813 Phpapp01

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SVN Basic Tutorial 12040823s2813 Phpapp01

Uploaded by

Copyright:

Available Formats

SVN BASIC TUTORIAL

Removal of direct deploy

Why not to directly deploy

SVN development cycle

SVN development (in SVN

Will make some examples with

Fetching an existing project

Fetching an existing project

Fetching an existing project

Fetching an existing project

Fetching an existing project

The .svn directory is used by subversion to keep track of

Fetching an existing project

Adding some files to the

Adding some files to the

Adding some files to the

Adding some files to the

Adding some files to the

Updating working copy

Updating working copy

Updating working copy

Deploy with SVN

Merging and conflicts

echo hello to;

RED = changed by developer

How merging works

How merging works

How merging works

What if SVN cant merge?

index.php.r8 is the version before the

Next major version update

Bugfix for a known bug

New feature that has to be

Switching working copy

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

Like normal conflict merging!

First you switch to the branch you

Then you merge a set of revision

Then SVN will merge any conflicts

$ svn ci -m merging changes from newlayout branch

Except that you NEVER commit on tags!

Update your projects before working

Do not commit broken code/functionality!

Commit as soon as a piece of the

Branch life should not be too long

Long living branches increase merge

This forces you to keep small units of work

Every commit should have a purpose.

Never commit generated code/data!

Generated code can produce dozens of useless commits,

Examples of BAD commit messages:

Saving work of 10/3/2010

Examples of GOOD commit messages:

Adding CSS definitions needed to create a lightbox overlay

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

(yes, multiline commits are allowed!)

If using an issue tracker