Spring Boot vs Quarkus the ultimate battle - DevoxxUK
Version Control with SVN
1. Version Control with SVN
by Michelangelo van Dam
PHPBelgium meeting 22/10/2008
Cafe Sport Leuven
1
1
2. 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
3. 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
4. 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
5. 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
6. 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
7. 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
10. 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
12. Version management
• all code resides in “trunk”
• code version are detached in “branches”
• snapshots for releases are “tagged”
12
12
13. 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
14. 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
15. Trunk
• trunk is where all code resides
– except custom development
• has always the latest version
• is not always the most stable version
15
15
16. Branch
• two kind of branches exists
– custom development branches
– version branches
16
16
17. 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
18. 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
19. 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
20. More than just version control
• Subversion provides more features
– File portability
– Keyword substitution
– Locking
– Externals
– Peg and Operative revisions
– Network model
– Hooks
20
20
21. 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
23. 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
24. 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
25. 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
26. 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
27. 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
28. 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
29. Cool things with SVN hooks
Lorna Jane’s Nabaztag
Responding on SVN commits
http://www.flickr.com/photos/lornajane/2592602734/
29
29
30. 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
31. 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