Subversion Branching And Merging (using TortoiseSVN)

A sad fact of life is that you sometimes have to do things you don't agree with. For my last 2 clients (one for SSW - Pfizer and one for Oakton - Lend Lease), I have had to use Subversion (SVN) rather than Microsoft's championed Team Foundation System (TFS). One of the features lacking in subversion is what TFS calls shelving.

You've got to use what you've got (SVN) to your best advantage but Andre Gallo, one of my colleagues from Lend Lease, has been struggling with it. In particular he's been having some serious issues with getting the current HEAD version from the trunk into his revision - and from the revision to the main trunk of our source code repository. Here are some of the discoveries I made this afternoon when trying to get branching and merging working smoothly for Andre, myself and the rest of our team:

We received some documentation from one of my colleagues from Oakton (Alexey Greyze) to assist us getting up and running with a good branching solution using subversion. One thing from his documentation that I did not agree with is to have a branch per JIRA ticket (aka one branch per development task). I regard this as excessive and have decided on a much simpler file system/structure for our branching. One thing that is also not clear from the SVN documentation is the fact that the merge tool is used to replay changes on your current working copy - NOT to merge from one branch to the other (e.g. from the branch to the trunk) directly.

As is suggested by many articles (e.g. http://devnulled.com/content/2006/10/guide-and-best-practices-for-subversion-branching/), excessive merging between branches is complicated to work with and should be avoided. You should try and have as many developers working on the trunk (or a single branch e.g. the dev branch) as possible. This helps to avoid massive merging sessions after 2 weeks of changes that can cause problems. As one article put it "Branches are for the minority." . The only reason to use branches per developer is if you have a team where communication is difficult (which doesn't apply in our case) and it is hard to get them to fix up issues if they check bad code into the trunk/central branch.

We will keep it simple and just have the following structure:

1. /Dev folder
2. /Trunk folder
3. /Build folder (used by Cruise Control for daily builds)

One of the articles I came accross also helped us to understand how merging works with Branching can be found here:
http://nedbatchelder.com/text/quicksvnbranch.html

A CRITICAL point of understanding about the Tortoise SVN Merge dialog (and the SNV merge process in general) is that the "FROM" and "TO" sections of the dialog are not that you are merging between 2 different locations. Instead, the "FROM" and "TO" sections indicate that you are REPLAYING each change in a single location (e.g. http://subversion.apac.lendlease.com/svn/IT/Global/LendLease.IM/dev/davidklein/LPP-117) from revision 100 to revision HEAD on the folder that you right clicked on for the merge using SVN. If I right-clicked on the trunk folder and clicked merge, this would replay all changes logged on http://subversion.apac.lendlease.com/svn/IT/Global/LendLease.IM/dev/davidklein/LPP-117 betwen 100 and HEAD on my working copy of the trunk.

Note that this dialog is basically saying it is going to replay all the changes made between 100 and my head revision on my current working folder (ie the one I right clicked on and clicked "Merge")

When you are merging back to the trunk, you may also run into the following error:

Error: Unable to find repository location for 'http://subversion.apac.lendlease.com/svn/IT/Global/LendLease.MasterDataManager/trunk' in revision 32797

To fix this, you just need to change the revision number to the one after you did the branch. ie 32798 in this example.