Version Control with SVN
by Michelangelo van Dam
PHPBelgium meeting 22/10/2008
Cafe Sport Leuven
1
1

About me
Michelangelo van Dam
Enterprise PHP Consultant
Zend Certified Engineer
Co-founder PHPBelgium
Contributor Zend Framework
PHP Advocate
E-mail: dragonbe@gmail.com
Blog: http://dragonbe.com
Twitter: http://twitter.com/DragonBe
2
2

About this presentation
• Concepts of version control
• Management with subversion
• Life cycle of a project in subversion
• Parts and structures within subversion
• Advanced subversion tools
• New in release 1.5
3
3

What is version control ?
“Revision control (also known as version
control ...) is the management of multiple
revisions of the same unit of information.”
(source: Wikipedia:RevisionControl)
4
4

Version Control for PHP devs...
• version control provides
– management of versions of information
• code/tests
• configuration files
• documentation
– in a structured, standardized way
– with repositories
• centralized (SVN, CVS)
• decentralized (GIT)
5
5

Why need version control ?
• enables collaboration between developers
• centralized “main code” (trunk)
• custom code alongside main code (branching)
• eases release management (tags)
• rollback to previous revisions
• integration with other tools
6
6

Subversion (SVN)
• Subversion (http://subversion.tigris.org)
• more advanced than CVS
• less complex than GIT
• integrates well with other tools
(trac, gforge, jira, ...)
• supported by many tools
(Zend Studio, TurtoiseSVN, Subversion CLI)
7
7

An example project in trac
8
8

SVN browser in Zend Studio
9
9

Code management with SVN
• many developers create much code
• code is committed to a central repository
– conflicts trigger warnings
• user and groups can be defined
• different versions can co-exist
• access management for named and
anonymous access rights
10
10

Subversion authentication
• svnserve daemon
$ svn svn://server/project/trunk
• svnserve daemon over SSH
$ svn svn+ssh://server/project/trunk
• Apache webserver
http://svn.server/project/trunk
11
11

Version management
• all code resides in “trunk”
• code version are detached in “branches”
• snapshots for releases are “tagged”
12
12

Release management
• a release is a snapshot of a version branch
• are being deployed to server environments
• for live or production environments
don’t check out in document root !
– use release folders
svn co svn://server/myproj/tags/rel-1.0 /web/myproj-rel-1.0
– create symlink to it
ln -s /web/myproj-rel-1.0 /web/myproj
13
13

SVN life cycle
custom dev branch
v1.0 v1.1
Trunk
bug fix
rel-1.1.1 rel-1.1.2
rel-1.0.1 rel-1.0.2
14
14

Trunk
• trunk is where all code resides
– except custom development
• has always the latest version
• is not always the most stable version
15
15

Branch
• two kind of branches exists
– custom development branches
– version branches
16
16

Custom development
• code that changes many things in trunk
• are best put in a separate branch
• maintained by their developer(s)
• and merged back into trunk
– after the merge, the branch is removed
• when changes are done and tested
17
17

Versions
• are maintained in branches
• have a long lifetime cycle (several years)
• differ from each other
– because of new code base, framework, language
• have a common base = trunk
• fixes from versions go into trunk
• back port fixes go from trunk into version
18
18

Tags
• tags are snapshots
• usually made on version branches
• can also be made on “trunk”
• are deployed (exported) to staging
environments
• are used to keep track what’s happened
between releases (change log)
19
19

More than just version control
• Subversion provides more features
– File portability
– Keyword substitution
– Locking
– Externals
– Peg and Operative revisions
– Network model
– Hooks
20
20

File portability
• Line endings differ on different OSses
– are ignored when checking modifications
• Mime-types differ from their extensions
– binary and non-binary files are tested on content
21
21

Keyword substitution
• Only a few keywords are substitute
– $Date:$ › $Date: 2008-10-22 20:00:00 +0100 (Wed,
22 Oct 2008) $
– $Revision:$ › $Revision: 144 $
– $Author:$ › $Author: svnusername $
– $HeadUrl:$ › $HeadUrl: http://svn.test.be/trunk $
– $Id:$ › $Id: file.php 148 2008-10-22 20:00:00Z
svnusername $
22
22

Locking
• working copy locks
– exclusive right to a working copy
– clears with “svn cleanup”
• database locks
– ensures database integrity
– only admins can remove this lock
23
23

Externals
• Externals provide an easy way to
– include other internal or external projects
– without having to care about there revisions
• Examples:
– Zend Framework as svn:externals on library path
– project that includes many smaller projects
24
24

Peg and Operative revisions
• automated handling of
– moving files
– deleting and creating new files with same name
• Using specific syntax
– $ svn command -r OPERATIVE-REV item@PEG-REV
25
25

Network model
• Can run it’s own svnserve
– pros: no dependencies, works with ssh for extra
security
– contras: need svnclient to connect
• Or in combination with Apache webserver
– pros: works with any http-client
– contras: overkill for small projects, requires
mod_dav_svn, more difficult to set up
26
26

Hooks
• Hooks facilitate actions to be taken
– before a commit starts (validate rights)
– after a commit (send e-mail, update tracker, ...)
– before or after a revision change (notifications)
• Can easily be incorporated with tools
– tracking tools
– integration tools (Lorna Jane’s Nabaztag)
– mailing and logging systems
27
27

Hooks execute moments
• basic commit moments:
– start-commit:
• runs before commit transaction started
– pre-commit:
• runs right before commit transaction is promoted
– post-commit:
• runs after the commit transaction is finished
– ...
28
28

Cool things with SVN hooks
Lorna Jane’s Nabaztag
Responding on SVN commits
http://www.flickr.com/photos/lornajane/2592602734/
29
29

New features in Subversion v1.5
• Merge tracking (foundational)
• Sparse checkouts (via new --depth option)
• Interactive conflict resolution
• Changelist support
• Relative URLs, peg revisions in svn:externals
• Cyrus SASL support for ra_svn and svnserve
• ... (more on http://subversion.tigris.org/
svn_1.5_releasenotes.html)
30
30

Summary
• manageable file change history
• better collaboration between developers
• clearer release management
• more then one version of same code base
• easier to rollback in case of emergency
31
31

Thank you...
Questions ?
Michelangelo van Dam - dragonbe@gmail.com
http://slideshare.net/PHPBelgium/version-control-with-svn-presentation
32
32