SVN

Subversion
User Training
Adjusted for the VU Software Configuration Management course
All SubTrain materials are published under the Creative Commons Attribution License and contain material from other works published under the same
license. To view a copy of this license, visit http://creativecommons.org/licenses/by/2.0/ or send a letter to Creative Commons, 559 Nathan
AbbottWay, Stanford, California 94305, USA. Special thanks to the authors of the comprehensive subversion book book Version Control with
Subversion by Ben Collins-Sussman, Brian W. Fitzpatrick, and C. Michael Pilato. You are free to adjust the materials to your needs. Please respect
our work by adding the SubTrain logo to your slides.
Agenda
1. Part I
a)
b)
c)
Architecture of Subversion
The working cycle
Dos and don'ts
2. Part II
a)
b)
c)
Team Work I
Locking
Tagging
3. Part III
a)
b)
c)
Branching
Merging
Team Work II
Polarion Software 2007
Subtrain - SVN User Training
References
Version Control with Subversion

B. Collins-Sussman
B.W. Fitzpatrick
C. Michael Pilato
Available at http://svnbook.red-bean.com/
Part I
Architecture of Subversion
The working cycle
Dos and don'ts
Subversion Architecture
Architectural Overview
Repository Layout
Global Revisions
Overview
Client Interface
Repository Interface
FSFS
Apache
mod_dav
GUI client
apps
Repository
access
mod_dav_svn
DAV
Internet
Client
Library
(Any TCP/IP Network)
svnserve
SVN
Commandline
client apps
Subversion
Repository
Local
Working Copy
Management
Library
Berkley DB
Access URLs
file://
Direct repository access to local or network drive.)
http://
Access via WebDAV protocol to Subversion-aware Apache server.)
https://
Same as http://, but with SSL encryption.
svn://
Unauthenticated TCP/IP access via custom protocol to an svnserve server.
svn+ssh://
Authenticated, encrytped TCP/IP access via custom protocol to an svnserve server.
Access URLs
file://hostname/path/to/repos
On local machines the hostname part must be absent or localhost.

This results in a path like this one:
file:///path/to/repos
On Windows you have to specify the drive where to find the
repository:
file:///X:/path/to/repos
Repository Layout
Root
Root
trunk
Project 1
trunk
Project 1
tags
Project 2
branches
tags
Project 1
Project 2
Project 2
trunk
branches
tags
branches
Project 1
Project 2
Repository Layout
Root
Project 1
trunk
Main line of development
tags
Releases
Preparation of releases, bug fixing
branches
Project 2
trunk
tags
branches
10
The revision numbers
0
11
The revision numbers
Every commit produces a new unique revision number.
The revision numbers are unique per repository.
A commit in Subversion is atomic just like a database transaction
(technically there is no difference).
12
Typical Working Cycle

Overview
Import
Checkout
Looking for Changes
Commit
Add, Delete and Move
Undoing Changes
The Working Cycle

Submit your changes
get content
svn commit
svn checkout
svn update
106
100
Merge your changes
Resolve conflicts
Make changes
svn diff
svn resolved
Subversion
Repository
svn add
svn move
svn delete
105
See what was changed

in the repository in the meantime
Update your local copy

svn update
svn status -u
14
The Working Cycle

Importing a Project into Subversion
The client machine
Repository Server
Import the locally stored project

tree to the repository server.
15
The Working Cycle

Importing a Project via TortoiseSVN
16
The Working Cycle

Importing a Project via TortoiseSVN
17
The Working Cycle

Check Out
The client machine
Repository Server
Check out a working copy
A check out will transfer the projects content

from the repository server
to the client machine.
18
The Working Cycle

Check Out via TortoiseSVN
19
The Working Cycle

Check Out via TortoiseSVN
20
The working cycle

Looking for changes via TortoiseSVN
Status normal
Locked
Added file/directory
Modified
deleted file/directory
Read only
21
The working cycle

Looking for changes via TortoiseSVN
Context Menu TortoiseSVN -> Check For Modifications
22
The Working Cycle

Commit Your Changes via
TortoiseSVN
23
The Working Cycle

Commit Your Changes via
TortoiseSVN
24
The Working Cycle

Adding Files/Directories via
TortoiseSVN
25
The Working Cycle

Removing Files via TortoiseSVN
26
The Working Cycle

Removing Files via TortoiseSVN
Status output for removed files with TortoiseSVN
Context Menu TortoiseSVN -> Check For Modifications
27
The Working Cycle

Copying Files via TortoiseSVN
Move/Copy files/directories via TortoiseSVN:
If you use the right mouse button you will see the context menu for
moving and and copying files.
28
The Working Cycle

Check What Was Changed via
TortoiseSVN
Check what has changed in the WC via TortoiseSVN:
Context Menu -> Diff
29
The Working Cycle

Warning
WARNING
Never move, delete, copy files or
create directories without the
Subversion commands:
svn
svn
svn
svn
move
delete
copy
mkdir
Easy if using TortoiseSVN as it is

integrated directly in Windows
Explorer
30
The Working Cycle

Pristine Copy
How does the revert operation work?
Subversion holds a complete pristine copy of the checked out working
copy in its .svn directory structure.

Every operation can be rolled back:
add
remove
copy
delete
mkdir
But only as long as it is uncommitted.
31
Dos and Donts
Dos and Dont's

Do not commit just a single file if your change applies to more than
one file.
Commit the complete directory tree beginning at the root of your
working copy.
Make sure your change reflects a single purpose: fixing a specific bug,
the addition of a new feature, or some specific task.
But why?
33
Dos and Dont's

Log messages should describe the change from a technical point of
view.
Put in a reference to Ticket/Issue/Bug Id.
Don't write log messages like:
Removed line 4
Inserted line 10 in file etc.
The above is the job of Subversion not yours ;-)
Often Log messages have to follow policies given by the company. Pay
attention to yours.
34
Exercises
Each person creates a repository
The groupaccount is \\solo\pracscm
Use your id as repository name
Practice the discussed SubVersion concepts
Part II
Team Work I
Locking
Tagging
Team Work I
Multiple Working Copies
Managing Conflicts
Team Work I
Team work means several people work on the same project.

Each team member will have to change either source code or
documentation etc.
Each team member has to check out the complete project or parts of
it.
38
Team Work I
Check out the actual state of the project from the repository. (WC
working copy)
39
Team Work I
Conflicts
Sally and Harry check out the same project from the repository.
checkout
p1
checkout p1
Harry
Sally
40
Team Work I
Conflicts
Both begin to edit the same file in their copies and their changes
overlap.
Harry
Sally
41
Team Work I
Conflicts
Sally changes the README file.
42
Team Work I
Conflicts
Sally commits her work first.
commit
Harry
Sally
43
3 Team work I
Conflicts
Harry has changed the README file as well.
44
Team Work I
Conflicts
Harry tries to commit his work after Sally.
Commit will show a message:
Out of date...
Harry
Sally
45
Team Work I
Conflicts
Harry has to update his local working copy to get Sallys changes.
Import the changes from the

Repository into the local WC using
svn update command; the
overlapping file will be flagged as
conflict.
conflict
Harry
Sally
46
Team Work I
Conflicts
How to solve a conflict?
No tool is able to handle the conflict.
Only humans are capable of understanding and making the
necessary intelligent choices.
The two members (in the example) have to discuss the conflict as
well as possible solutions.
47
Team Work I
Conflicts
How does Subversion support you?
For every conflicted file Subversion places up to three extra unversioned

files in your working copy:
1. filename.mine
This is your file as it existed in your working copy before you updated your working
copythat is, without conflict markers. This file has your latest changes in it and
nothing else. (If Subversion considers the file to be non mergeable, then the .mine
file isn't created, since it would be identical to the working file.)
2. filename.rOLDREV
This is the file that was the BASE revision before you updated your working copy.
That is, the file that you checked out before you made your latest edits.
3. filename.rNEWREV
This is the file that your Subversion client just received from the server when you
updated your working copy. This file corresponds to the HEAD revision of the
repository.
48
Team Work I
Conflicts
Edit-Conflict of TortoiseSVN (accessible via context menu):
49
Team Work I
Conflicts
Conflict has been solved by a human being. It is clear now which part
of the code or documentation is the right one.
Before you can check in the merged file you have to tell Subversion
that the conflict has been solved.
50
Team Work I
Conflicts
You have to tell Subversion that you solved the conflict with:
svn resolved destination
(1)The Subversion resolved-command.

(2)The destination of the operation file/directory.
If you want to go through a whole directory of files, use the -recursive flag.
51
Team Work I
Conflicts
Harry can now commit his changes and the merged files.
commit
Harry
Sally
52
Team Work I
Conflicts
In the last step Sally has to update her local working copy.
update
Harry
Sally
Now both share the same state.

53
Team Work I
Conflicts
Reasons for Conflicts:
Two members of a team work on the same files and overlapping areas.
In the end it can be reduced to one critical factor:
User communication.
It must be clear who is working on what.
How often do conflicts arise?

rarely.
54
Locking
Locking Models
Optimistic Locking
Pessimistic Locking
Locking
Copy-Edit-Merge Model
The default model of Subversion is the copy-edit-merge model.
This means:
Check out a working copy

Make any edits
merge changes from server
Commit your changes
But there are situations in which this model might cause problems.
56
Locking
The Two Models
You cant use the copy-modify-merge model with files like Word or
Excel (this applies for other types too) because you cant merge those
files.
So you have to go another way. There are two possible solutions:
The first one is to explicit lock the file before you start to edit a file of the
above type (called optimistic locking).
The second one is to use the pessimistic-locking variety.
57
Locking
Optimistic Locking
Explicit Locking strategy:
Before you start working on a non-mergeable file (like Word etc.) you
have to request a lock for the given file.

If you get the lock you can start working on it.
When you are done with your changes, you commit whereas the lock will
be released at the same time.
Advantages:
Its simple.
Its error-prone.
Disadvantages:
You miss to unlock a file e.g. before you are going on vacation etc.
(You can steal locks ;-))

Everyone has to apply this procedure as a default rule.
No lock reminder for the user.
58
Locking
Optimistic Locking
Tell Subversion to get a lock via TortoiseSVN:
59
Locking
Optimistic Locking
Tell Subversion to get a lock via TortoiseSVN:
60
Locking
Optimistic Locking
We got the lock via TortoiseSVN:
61
Locking
Optimistic Locking
Try to lock an already locked file with TortoiseSVN:
62
Locking
Optimistic Locking
Check if a file has been locked on the server:
63
Locking
Optimistic Locking
To unlock a file just type the svn unlock command with a particular
destination.
Or it will be unlocked automatically if you commit your changes back
to the repository.
64
Locking
Pessimistic Locking
Pessimistic-Locking:
You can put a special property to a file svn:needs-lock with any value.
The result is if you check out a file with the property set, the file will be
marked as read-only.
Advantage:
The application you use with this type of file will give you a reminder about
the read-only state.
Disadvantage:
The system isn't flawless, either. It's possible that even when a file has the
property, the read-only reminder won't always work. Sometimes applications

misbehave and hijack the read-only file, silently allowing users to edit and
save the file anyway. Unfortunately there's not much Subversion can do about
this.
65
Tagging
Why Tagging
Tagging by Copy
Tagging
Why Tagging?
Why do we need tags?
Mark a release state of a product.

Mark a snapshot of the current development.
Typical Release names:
Release 1.0.0, Release 2.3.1, PRODUCT 1.0.0RC1 etc.

A Tag name must be unique to mark all components of the given
product (source code and documentation) and is used to reproduce
the state of the tag in the future.
67
Tagging
Why Tagging?
If we take a look at the architecture chapter we really dont need a
special tag. We only need to write down the revision number.
But human beings have other requirements.
They like to have self-explanatory tag names which are more handy.
But the question is:
Where to put the tag information in the repository?
68
Tagging
Tagging by Copy
Root
Project 1
trunk
To create a release tag just

copy
tags
Release 1
anyway you have the revision

number
69
Tagging
Tagging by Copy via TortoiseSVN
Create a tag for the trunk development via TortoiseSVN:
Context Menu -> Branch/Tags (You have to be in your working copy):
70
Tagging
Tagging by Copy via TortoiseSVN
Create a tag for the trunk development via TortoiseSVN:
Or via Repos-Browser and context menu -> Copy to

71
Exercises
Work in groups of 2 persons on a single repository
Part III
Branching
Merging
Team Work II
Branching
Why Branching
Creating Branches
Using Branches
Branches
Why Branching?
Assume the following situation:
You have created a great product and it has been delivered to your
customer.
Before you delivered the product you have created a tag, let us name it
Release 1.0.0
Your current development crew is working on Release 1.1.0 with new
features.
And now Murphys Law caught you:
Your customer calls you and reports that he has found a bug in your
software.
75
Branches
Why Branching?
The development has continued after the release of RELEASE 1.0.0
You want to fix the bug
to satisfy your customer!
In your current development
RELEASE 1.0.0
you have enhanced many of
the products functions
but you dont want to deliver
a product with more
features and you havent
finished testing yet.
How to solve this situation?
Main line of development
76
Branches
Why Branching?
Based on the tag youve created during the delivery you can check out
the exact state of the delivery.
You create a Branch to
fix the bug in the software.
RELEASE 1.0.0
After you have fixed the bug
you can tag the Branch and
BUGFIX_BRANCH
deliver another version to the
customer.
Your customer is satisfied
RELEASE
that you fixed the bug
1.0.1
so fast.
You havent disturbed the
current development.
77
Branches
Creating Branches
Root
Calc
trunk
branches
my-calc branch
Paint
trunk
branches
78
Branches
Using Branches
Based on your companys policy you may have subdirectories under

the branches directory in the repository:
branches/release-candidates
branches/sub-projects
branches/user-branches
This differs much from company to company.
79
Branches
Using Branches
You would like to work on the branch to fix the bug.
You can do it in two ways:
Check out a complete new
working copy from the

branch.
Or switch your current
working copy to the
particular branch.
RELEASE 1.0.0
BUGFIX_BRANCH
RELEASE
1.0.1
80
Branches
Using Branches
Create a branch from a release tag via TortoiseSVN:
Context Menu -> Copy to
81
Branches
Using Branches
82
Branches
Using Branches
83
Branches
Using Branches
Fix the bug through doing the necessary modifications and finally
commit the changes to the branch.
After having fixed the bug on the branch create a tag to mark the
new release which can be delivered to the customer.
Create the new Release Tag:

svn copy
file:///home/kama/repos/project1/branches/BUGFIX_BRANCH
file:///home/kama/repos/project1/tags/RELEASE-1.0.1
-m- Fixed Release 1.0.1
84
Merging
Merging from a Branch
Merge Tracking
Best Practices
Merging
Merging From a Branch
Whats with the bug you've fixed on the bug-fix-branch?
What about your current development?
You have to merge the
changes made in the branch
back to the main line.
RELEASE 1.0.0
BUGFIX_BRANCH
267
RELEASE
1.0.1
Merge back
86
Merging
Merging From a Branch via
TortoiseSVN
Merging of a branch via TortoiseSVN:
87
Merging
TortoiseSVN
88
Merging
TortoiseSVN
89
Merging
Merge Tracking
Merge tracking:
Subversion does not have any function to track merges which have been
done e.g. to prevent you to merge a branch a second time
You have to do it on your own!
90
Merging
Merge Tracking
Best Practices:
If you need to create a branch, you should do it from a completely

committed working copy. This prevents you from becoming confused.
If you merge check out a clean copy into another directory.

Otherwise you can't go back using svn revert.
After you've merged commit the changes and provide a log message with
information on which revision/branch you have merged (merge tracking).
You can first test the merge using the --dry-run flag of the merge command.
91
Merging
Warning
WARNING:
WARNING
From the technical view a branch and a tag are the same.
BUT:
The intention of a tag is that it should be used as read-only area
whereas a branch is used to continue development (interim code,

bug-fixing, release candidate etc.).
Technically you can use a tag to continue development and check in
etc. but you shouldnt do it.
So in other words the difference between a tag and a branch is just
an agreement.
92
Team Work II
Developer Branches
Feature Branches
Team Work II
Developer Branches
Separation of team members can be realized with branches.

One branch per team member or several members on a branch - the
decision is based on the size of the teams.
Main line
Member 2
Member 1
94
Team Work II
Developer Branches
Advantages using branches for team work:
No changes during development on the main line needed => Code
stability.
Every team member can work in its own environment.
Disadvantages:
Sometimes the mainline and the branch will diverge if the branch lives
too long.
95
Team Work II
Feature Branches
Separation by features (one branch each).
Main line
Feature 2
Feature 1
96
Exercises
Work in groups of 4 persons on a single repository

SVN

Diunggah oleh

Informasi Dokumen

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

SVN

Diunggah oleh

Hak Cipta:

Format Tersedia

Subversion

Polarion Software 2007

Subtrain - SVN User Training

Version Control with Subversion

Polarion Software 2007

Subtrain - SVN User Training

(Any TCP/IP Network)

Polarion Software 2007

Subtrain - SVN User Training

Polarion Software 2007

Subtrain - SVN User Training

On local machines the hostname part must be absent or localhost.

Polarion Software 2007

Subtrain - SVN User Training

Polarion Software 2007

Subtrain - SVN User Training

Main line of development

Polarion Software 2007

Subtrain - SVN User Training

Polarion Software 2007

Subtrain - SVN User Training

Polarion Software 2007

Subtrain - SVN User Training

Typical Working Cycle

The Working Cycle

See what was changed

Update your local copy

Polarion Software 2007

Subtrain - SVN User Training

The Working Cycle

Import the locally stored project

Polarion Software 2007

Subtrain - SVN User Training

The Working Cycle

Polarion Software 2007

Subtrain - SVN User Training

The Working Cycle

Polarion Software 2007

Subtrain - SVN User Training

The Working Cycle

Check out a working copy

A check out will transfer the projects content

Polarion Software 2007

Subtrain - SVN User Training

The Working Cycle

Polarion Software 2007

Subtrain - SVN User Training

The Working Cycle

Polarion Software 2007

Subtrain - SVN User Training

The working cycle

Polarion Software 2007

Subtrain - SVN User Training

The working cycle

Context Menu TortoiseSVN -> Check For Modifications

Polarion Software 2007

Subtrain - SVN User Training

The Working Cycle

Polarion Software 2007

Subtrain - SVN User Training

The Working Cycle

Polarion Software 2007

Subtrain - SVN User Training

The Working Cycle