Using a revision control system that tracks changes in source code with ways to manage your code in separate branches and tag revisions as releases is a bare minimum for developers. This presentation highlights the importance of using a version control system Subversion.

1. Versioning for developers
Michelangelo van Dam
Macq Electronique 2010 Brussels, Belgium

2. Michelangelo van Dam
• Independent Consultant
• Zend Certified Engineer (ZCE)
- PHP 4 & PHP 5
- Zend Framework
• Co-Founder of PHPBenelux
• Shepherd of “elephpant” herds

3. T AIL O RM A D E S O L U T I O N S
Macq électronique, manufacturer and developer, proposes
you a whole series of electronic and computing-processing
solutions for industry, building and road traffic.
Macq électronique has set itself two objectives which are
essential for our company :
developing with competence and innovation
earning the confidence of our customers
Macq électronique presents many references carried out
the last few years which attest to its human and
technical abilities to meet with the greatest efficiency
the needs of its customers.
For more information, please check out our website
http://www.macqel.eu

4. 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

5. 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)

6. Versioning for developers
•- 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)

7. Why need versioning ?
• 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

8. 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, TortoiseSVN, Subversion CLI)

9. An example project in trac

10. SVN browser Zend Studio

11. Code managing 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

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

13. Version management
• all code resides in “trunk”
• code revisions are detached in “branches”
• snapshots for releases are “tagged”

14. Subversion Schema

15. Putting a project into SVN
Say you’ve started project FooBar with following files:
/FooBar
/Foo.php
/Bar.php
To put it on a Subversion repository:
$ svn import -m “new project” FooBar http://svn.server/
FooBar/trunk

16. Getting code from SVN
A new team member needs to work on the FooBar project
He needs to get the project from Subversion
To get it from a Subversion repository:
$ svn checkout http://svn.server/FooBar/trunk FooBar
This will fetch the latest revision (HEAD) from the TRUNK
and creates a local FooBar directory

17. Updating code in SVN
After a well deserved holiday, you need to continue working
on the FooBar project
You need to get updates of the project from Subversion
To update your working copy from Subversion repository:
$ svn update /FooBar
This will update your working copy with the latest revision
(HEAD) from the TRUNK

18. Committing back to SVN
You’re working hard on FooBar and you need to commit
your changes back to Subversion.
To commit changes back to Subversion repository:
$ svn commit -m “Added some cool stuff”
This will commit changes in your code to the TRUNK.

19. Best practice
Update before committing
Update after committing
Commit small development chunks
Commit often

20. Release management
• a release is a snapshot of a version branch
• are being deployed to server environments
(DEV, TEST, ACC, PROD, ...)
•- 2 common methods to release code
symlink deployment
- subversion export

21. Symlink Deployment
•- On production server(s):
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
• Pro:
- simple
• Contra:
- renaming folders on server
- enabling FollowSymlinks

22. Subversion Export
• Exporting a release from subversion
svn export http://svn.server/project/tags/
release-1.0.2
• Pro:
- scheduled (automated) upgrades possible
- no further modifications necessary
• Contra:
- takes longer to switch back to previous release

23. SVN life cycle
feature branch
v1.0 v1.1
Trunk
bug fix
rel-1.1.1 rel-1.1.2
rel-1.0.1 rel-1.0.2

24. Trunk
•- trunk is where all code resides
except custom development
• has always the latest version
• is not always the most stable version

25. Branch
•- two kind of branches exists
feature branches
- release branches

26. Feature Branches
• 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

27. Release Branches
• 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

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

29. More than just versioning
•- Subversion provides more features
File portability
- Keyword substitution
- Locking
- Externals
- Peg and Operative revisions
- Network model
- Hooks

30. File portability
•- Line endings differ on different OS’s
are ignored when checking modifications
•- Mime-types differ from their extensions
binary and non-binary files are tested on content

31. Keyword substitution
•- Only a few keywords are substituted
$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 $

32. 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
• conflicts with the purpose of revision control

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

34. Peg & 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

35. Network model
•- Can run its 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

36. 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

37. 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
...

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

39. Automated builds
•- With SVN and Phing (PHP Build tool)
nightly checkout of code base
- running tools to enhance code
• PHPDocumentator (automated API docs)
• PHP_CodeSniffer (checks code for standards)
• PHPLint (checks code for syntax errors)
• PHPUnit (unit testing for PHP)
-
• …
creating a package (including docs, tests, reports)

40. New features in SVN 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)

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

42. Recommended Reading
Version Control with Subversion, 2nd Edition
(O’Reilley Media, Inc)
by C. Michael Pilato; Ben Collins-Sussman; Brian W. Fitzpatrick
also online: http://svnbook.red-bean.com
Managing Software Development with Trac and Subversion
(Packt Publishing)
by David J Murphy

43. Recommended Reading
Subversion Version Control:
Using the Subversion Version Control System in Development Projects
(Bruce Perens' Open Source Series)
by William Nagel

44. Credits
Wikipedia Logo
http://commons.wikimedia.org/wiki/File:Wikipedia-logo.png

45. Thank you !
Slides on Slideshare
http://www.slideshare.net/group/macqel
Give feedback on Joind.in
http://joind.in/1260