practical benefits of Subversion

I recently worked with a legacy version control system and found myself missing Subversion instantly. As a consultant, I often work with clients that are using in-house processes/software to manage project artifacts.  I've grown used to many of SVN's features and just assumed everyone was using something comparable these days. Here are my notes on some of the practical benefits of using Subversion that I think apply to most projects...

core features/benefits

• atomic commits
• one transaction to add/update/delete files
• promotes grouping related changes together in one commit to easily identify and revert
• full revision history retained for files that are renamed, copied, moved or removed
• no file locking (by design)
• file locking is extremely counter-productive (especially for large teams in multiple timezones)
• SVN's automatic merging and conflict resolution tools make locking unnecessary
• working copy of files are always writable and all changes are local until committed
  
• allows you to easily revert unwanted changes at commit time
• fast and flexible update/commits
• all tasks can be done from any level easily (updates, commits, merges, reverts, etc)
• branching and tagging are cheap operations
• simple to create a tag/branch and merge between them
• ease of access to the commit log
• provides high visibility to changes, file history, integrated file comparison
• ease of reverting changes to a file or an entire commit
• easy to setup email triggers (on checkins to keep team informed of changes, etc)
• integrates with everything
• windows explorer integration via Tortoise
• with leading IDEs (Eclipse, IntelliJ)
• Agile/continuous integration tools (Atlassian, Jira, Fisheye, TeamCity, Hudson, etc.)
• various websites to provide project/committer stats (Ohloh, etc)
• ease of setup and administration

benefits in practice (using Windows and Tortoise)

• syncing up my local environment
• open Windows Explorer and navigate to the root directory of my project
• right-click and choose 'TortoiseSVN->Commit'
• sounds counter-intuitive, but this show me a quick view of uncommitted local changes (aka 'mock commit')
• reminds me what I was working on
• lets me right-click on any files and choose 'compare with base' to get an instant diff
• once I'm recalibrated to the project and any in-progress changes, I cancel the commit...
• update my local working code
  
• switch to another branch (if necessary)
  
• if I need to work on another branch than what is currently selected, then I can switch to it easily
• right-click on project and choose 'TortoiseSVN->Switch'
• enter the SVN URL of the project I need to switch to
• click 'OK' to sync up with my local files
• otherwise, right-click and choose 'SVN Update'
  
• this syncs up my local working directory with the latest changes in the repository
• again, I can right-click on any files to compare them my local copy (to see what has changed)
• any conflicts are marked (rare)
• I can choose to either resolve it now or later, choose to use my version, or choose to use the repository version
• working on bug fixes/enhancements
  
• work on a single feature at a time
• make all related changes, write any necessary unit tests and test locally (of course)
• once complete, I commit the change...
• flip back to Explorer (can also be done with Eclipse SVN plugins)
• right-click on the project and choose 'TortoiseSVN->SVN Update' (optional)
• only necessary if you are working with a large development team or its been a while since I last updated from SVN
• this will insure that there weren't any other changes that might affect my commit
• right-click on the base project directory and choose 'TortoiseSVN->SVN Commit'
• dialogue box comes up to review my changes
• right-click on any files in question, revert as necessary
• check/uncheck the files I want to commit
• enter a quick comment referencing the bug/enhancement worked on and a description of the change
• click 'OK' to commit the changes
• working on major refactoring or large feature development
• I don't want this to affect the trunk, so I create a new development branch
• right-click on the project root and choose 'TortoiseSVN->Branch/Tag'
• in the dialogue box
• enter a new directory for your branch (generally /branches/<branch name>)
• enter a comment about the purpose of the branch
• click 'OK'...
• switch your local working directory to use the branch you just created (see instructions above)
• that is it...you now have a development branch (whole process takes about 30 seconds unless you have a large project)

summary
Overall, I think Subversion provides many productivity/quality control benefits and can even prove cost-effective to switch to mid-project.  Given that most open source Java development projects use SVN, I feel pretty confident that it continues to be a solid choice for the most projects.