A quick Google search will uncover countless tales of merge hell in Subversion but, when used correctly, branching and merging can be an invaluable tool for the Subversion developer. Essentially, a merge takes the differences between two separate revisions and applies them to the working copy path, using various invocations of the svn merge command. A merge never creates a new version, it always modifies a workfile, which is created by the merge and is then edited before the changes are committed back to the repository. Things do get a bit more complicated when conflicts occur during merging. Whenever two or more people have modified the same code, Subversion will flag up any conflicts when you attempt to merge.
While you’re not forced to resolve these conflicts immediately, you will be unable to commit your changes to the repository until all the conflicts have been resolved.
Merging is a crucial function for getting the most out of Subversion. Here are our ten tips, to help you avoid living through your own merge horror story:
1) Project partitioning – consider assigning bugs to team members based on the location of those bugs. This reduces the chances of different people modifying the same files, at the same time.
2) If confused, start over – if you make any errors (e.g you’ve merged the wrong working folder) you can always start over. The ‘Revert’ command will discard all changes.
3) Always start with a checkout or an update – always have the latest code from the trunk before you start resolving any conflicts, so make sure you have just performed a checkout or an update. If you’ve made changes to the working folder before you start the merge, it makes sense to commit that back to the repository, so you have a new revision of what the code looked like before you started your merge.
4) 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.
5) Use appropriate log messages – make it easy for people to go in later and find out what merges happened, what changes were made, etc. The more information you provide, the easier it will be two months later when someone asks whether the changes from a particular branch were ever incorporated into trunk development.
6) 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.
7) Isolate the merge – sometimes, it’s tempting to merge some changes and then add additional planned development before performing a commit. Try to avoid this, as it makes it difficult to separate which changes came from the merge, and which changes were made as part of the rest of the development.
8 ) Don’t become too isolated – even if it seems your changes have little to do with the rest of the team, by the time you’ve finished perfecting your branch, the trunk may have evolved to the point that it’s a nightmare to merge your changes. To avoid this, you should regularly replicate changes being made within the trunk, into your own branch, just to ensure they fit with your own changes.
9) Use commands – Subversion has some commands to help take the hassle out of merging. These include:
a) svn:mergeinfo – displays the history of merges made into a particular file or directory.
b) –dry-run – previews status codes that would be printed in a real merge, without actually applying any local changes to the working copy.
c) svn log – a svn log command on the /branches URL will display the entire history of a branch – even if a successfully merged branch is no longer visible in the /branches directory, it’s still a part of the repository’s history.
10) ….And don’t panic! – conflicts happen much less frequently than you would think. Whenever different team members can access the same files, there’s going to be occasional conflicts, but Subversion is a great tool for rectifying these conflicts when they do occur.
For more tips on merging, check out our free-to-download ‘Introduction to Branching and Merging’ and ‘Advanced Branching and Merging’ cheat sheets.
0 Responses to “Best Practices for Merging in Subversion”