High level view of some best practices to follow that many people starting to us SVN don't realize.

1. SVN Best Practices
Derek Gallo - NFi Studios
Friday, November 7, 2008 1

2. Introduction
• What is version control?
• Why use it?
• Revisions/Backup
• Logs
• Version/Release Management
• COLLABORATION
Friday, November 7, 2008 2

3. Basics
• Repository
• Checkout
• Commit
• Update
• Merge
Friday, November 7, 2008 3

4. Basic Rules of Thumb
• Comment, Comment, Comment
• Update and TEST before Commit
• Work from your own local copy
• Commit small autonomous changes
• Validate the files you are committing, you actually changed
• Watch for Conflicts
Friday, November 7, 2008 4

5. SVN Clients
• Windows = TortoiseSVN
• *NIX = command line
• IDE Integration
• There is no complete replacement for the command
line. Learn how to use it.
Friday, November 7, 2008 5

6. Starting a Project
• Create the project folder structure
• Trunk
• Main development location
• Branches
• For temporary isolation or codebase splits.
• Tags
• Snapshots of code at a given point in time
Friday, November 7, 2008 6

7. Repository Layout
• Single Project - One project per repository location.
• Pros
• Isolated revision numbers
• Isolated codebase
• Isolated security model
• Cons
• Isolated codebase
• Multiple Urls to remember
• Multiple locations to maintain
Friday, November 7, 2008 7

8. Repository Layout
• Multi-Project Layout - Several projects in one repository
• Pros
• Easy to merge code between projects
• Single url for all projects
• One repository to maintain
• Cons
• Revision numbers span across all projects
• Harder to isolate users to appropriate repositories
Friday, November 7, 2008 8

9. Use SVN Properties
• Link external libraries via svn externals
• Easier to update libraries or change versions.
• Helps enforce library separation
• More granular security model
• Use svn ignore appropriately
• configurations files
• os dependent files
• IDE project files
• User generated data
• Temporary folders & logs
Friday, November 7, 2008 9

10. Use Migrations
• They are not just for Rails
• Allows you to easily version your DB schema
• Doctrine for PHP supports migrations
• Be careful about migration numbers when committing
Friday, November 7, 2008 10

11. Branching/Tagging
• SVN and your development process/release cycle go hand in hand.
• Tag the completion of every milestone/sprint
• Create a tag for every version number
• Create a tag for the latest production release
• NEVER modify tags!
Friday, November 7, 2008 11

12. Branching/Tagging
• Create Branches to isolate experimental work.
• Create a Branch for every phase of your release cycle (QA, Staging, Beta, etc.)
• Make necessary fixes/changes in branch and “merge down” to trunk
• Keep branches for every released version
• “Freeze” externals when moving to release branches
Friday, November 7, 2008 12

13. Administration
• Apache mod_svn vs. svnserve
• Use SSL
• Use mod_authz
• Regular dumps to backup
Friday, November 7, 2008 13

14. Integrate w/ Project
Management
• Use software with SVN Browser
• Trac
• Unfuddle
• Log revision number in ticket updates
• Log ticket number in commit logs
Friday, November 7, 2008 14

15. Automation
• SVN Api and Hooks
• Policy enforcement using pre-commit
• Email notifications using post-commit
• Automate changelogs
• Track code-reviews using properties
• Automate Unit Tests at pre-commit
Friday, November 7, 2008 15

16. Additional Reading
• Version Control With Subversion
• O'Reilly Media.
• http://svnbook.red-bean.com/
• Subversion Version Control
• by William Nagel
• Prentice Hall
Friday, November 7, 2008 16