SVN Basic Tutorial: Formatvorlage Des Untertitelmasters Durch Klicken Bearbeiten Avoiding Headaches ™

SVN BASIC TUTORIAL
Formatvorlage
Avoidingdes
headaches
Untertitelmasters
™
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
Updating working copy
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
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
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

Parallel development
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!)
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”
-
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»
Optimal process
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

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

SVN Basic Tutorial: Formatvorlage Des Untertitelmasters Durch Klicken Bearbeiten Avoiding Headaches ™

Uploaded by

Copyright:

Available Formats

SVN Basic Tutorial: Formatvorlage Des Untertitelmasters Durch Klicken Bearbeiten Avoiding Headaches ™

Uploaded by

Document Information

Original Description:

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: Formatvorlage Des Untertitelmasters Durch Klicken Bearbeiten Avoiding Headaches ™

Uploaded by

Copyright:

Available Formats

SVN BASIC TUTORIAL

Developer 1 Staging Live

Developer 2 Staging Live

Designer 1 Staging Live

Designer 2 Staging Live

Developer 1 Staging Live

Developer 2 Staging Live

Designer 1 Staging Live

Designer 2 Staging Live

Developer 2 Issue Tracker

Developer 1 SVN Server Production Server

Get last project status from SVN server

Send work to SVN server Develop/Design

svn commit edit files

Will make some examples with TortoiseSVN and

echo ‘hello world ’;

RED = changed by developer

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

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

svn tries to merge svn update

SVN couldn’t merge

svn tries to merge svn update

echo ‘hello everybody’;

echo ‘goodbye everybody’;

RED = changed by developer

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

Manually edit conflicts svn update

SVN couldn’t merge svn tries to merge

Next major version update

A slightly different version of the site that t

(in TortoiseSVN it is under “branch/tag” in

You can now switch to a branch by doing

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

and you will be working on that copy

Like normal conflict merging!

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

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

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

Except that you NEVER commit on tags!

$ svn propset svn:externals

Externals are not part of the repository, they are

(Test before committing if possible!)

Long living branches increase merge

This forces you to keep small units of work

If possible, avoid multiple commits on

Generated code can produce dozens of useless commits,

The interfaces are still quite lightweight, but should be

«Fixed iframe width causing

Build (test first)

Commit (with appropriate message)

Resolve conflicts immediately

You might also like