So, you’ve downloaded Apache Subversion and have mastered the standard workflow – but this is just the start of what the world’s most popular version control system has to offer! In this post, we’ll dig a little deeper into Subversion and provide an overview of five features that can help you get even more out of version control, including discovering who is responsible for a specific change, and reverting to a previous version of your project.
1. Hook Scripts
Hook scripts are essentially programs that are triggered by a specific repository event. Usually, hook scripts are server side, but it’s also possible to run client side hook scripts. Hook scripts can be configured to perform the following tasks:
- Reporting on events (e.g emailing alerts when a commit occurs.)
- Testing for a pre-condition before allowing a commit (e.g checking a commit is accompanied by a log message)
- Blocking certain actions (e.g blocking a commit that contains multi-gigabyte files)
The hooks subdirectory is automatically created along with each new repository. By default, the hook files are saved as non-executable templates (.tmpl) To make changes to these files, you simply open them as text-based documents, enter the new text, and save the file in a new format. This format is different for each operating system, for example, in Windows, the format can be either .exe or .bat.
Need some more help getting started with hook scripts? Our ‘Introduction to Subversion Hook Scripts on Windows’ has a handy example of a pre-commit hook.
2. SVN Blame
Sometimes, you just need someone to blame! Subversion’s ‘blame’ command does exactly this: it displays each line of a particular file, along with who changed each line, and in which revision it was changed. This is obviously useful for pin-pointing who is responsible for bugs and broken code, but it can also be useful for finding out who you need to contact for more information about a particular part of your code.
To find out who is to blame for a particular change, right-click on the file in question and select ‘Blame’ from the TortoiseSVN menu.
In the TortoiseSVN dialog, select the revisions you wish to review, and click ‘Ok.’
This will bring up the TortoiseBlame dialog, where you can see the changes that were made to the file in each revision, and who is responsible for each change.
For more information on a particular revision, hover over that revision and a tooltip will appear displaying the revision’s log message.
Sometimes, there will be files in your working copy that don’t need to be placed under version control (you own notes, or a To Do checklist, for example) In these instances, Subversion’s ‘Ignore’ property can be used. Simply create/drag-and-drop the new file into your working copy, right-click to bring up the ‘TortoiseSVN’ sub-menu, select ‘Add to ignore list’ and select the file you wish to ignore.
This file will then be added to the ‘ignore’ list, and will not be accidentally committed back to the repository when you perform an ‘SVN Commit.’
4. Reverse Merge
Subversion remembers every change that’s made to its files and directories; a potential life-saver if you introduce a code-breaking feature in revision 12, and need to revert to a revision before it all went wrong. Recovering previous revisions in Subversion, is simply a matter of performing a reverse merge i.e merging the changes in your current revision, to an earlier revision. To perform a reverse merge with TortoiseSVN:
1) Select ‘Merge’ from the TortoiseSVN menu.
2) Select the ‘Merge a range of revisions’ option.
3) Select the revision you wish to revert to. Ensure the ‘Reverse merge’ option is selected.
4) The following dialog will present you with a number of options for merging – in most instances the default settings can be used. Click ‘Merge’ and Subversion will roll back to revision 11. Note, that the reverse merge only affects your working copy, so you must perform an ‘SVN Commit’ to commit your changes back to the repository.
5. Revert Command
Less drastic than a reverse merge, the revert command overwrites any local changes made to the working copy, with the code held in the repository, including any property changes and any scheduling operations that may have been set on the working copy. However, this command should be used with care: the revert command replaces all the changes made since your last commit, and once they are gone there is no way to recover them.
Need more help with your Apache Subversion installation? Every Monday, we’ll be publishing a new Tip of the Week at our blog, so keep checking back every week for all the latest tips!