Subversion Tip of the Week

Branching and Merging Best Practices

For those unfamiliar with version control, branching and merging in Apache Subversion can be a daunting prospect. But when used correctly, branching and merging can be one of the most powerful tools at your disposal. Here are some tips for avoiding merge hell – and those dreaded conflicts!

  • Isolate the merge – when performing a merge, do not add any additional planned development before performing the merge. This will make it difficult to distinguish where changes originated, and can cause major headaches if the team decides to roll back to previous revisions.
  • Use log messages – leave as much information as possible in your log messages (e.g what changes were made, why, and by whom, etc.) Log messages can be an invaluable source of information, if you need to revisit a particular revision at a later date. TortoiseSVN comes with functionality for ensuring that all team members leave appropriate log messages, including ‘Properties’ that are specific to TortoiseSVN. In this example, we’ll cover the ‘tsvn:logminsize’ property:

1) Select the properties option from the TortoiseSVN menu; this will bring up the properties dialog. Select ‘New’ property and click ‘Log sizes.’

2) You can now set the minimum number of characters for a commit message. TortoiseSVN will then block any commits with a log message shorter than the characters specified.

  • Use branches for new features and major bugs – this allows new features/bugs to be worked on immediately, regardless of the work currently underway in the trunk, or in neighbouring branches.
  • Delete unwanted branches – branches that are no longer required should be deleted. Note, deleting branches will have no effect on repository size, as the item will only be removed from the revision in question, and all subsequent revisions. It will still exist in all previous revisions, and can be viewed or recovered at any time.
  • Merge on logical checkpoints – in most cases, it makes sense to merge when the ‘from’ part of the merge (i.e the branch you’ve been working on) has reached the level of quality where changes are testable and compilable. Do not merge anytime an experimental new change has been made to the branch.
  • Merge soon – fix conflicts as soon as possible. The quicker you resolve conflicts and commit those changes back to the repository, the sooner the rest of your team can take your changes into account when working on their own part of the development effort.
  • If confused, start over – if you make any errors (for example, you’ve merged the wrong working folder) you can always start over. Simply right-click on your working copy and select ‘Revert’ to discard all local changes.

Need more Subversion know-how? After getting a great response from the Apache Subversion community in 2011, Subversion Live is back for 2012, bringing the Subversion community sessions covering everything from Subversion’s future, to expert-led best practices workshops, as well as the unique opportunity to meet the core Subversion committers.

0 Responses to “Subversion Tip of the Week”

  • No Comments

Leave a Reply