[NOTE]
Apologies for yesterday's incomplete post. It seems that lately I'm having problems to tell the difference between the "Preview" and the "Publish" buttons. Just the last 2 weeks I've published posts when all I wanted was preview them. And at least Google Reader is bloody quick fetching new posts because I deleted them just 20 seconds after publishing and still they got caught. Anyway, here we go again.
[/NOTE]
SVN is very well known for not doing a good job merging branches, or so they say. Most developers avoid branching at all costs (at least I was doing it) but that’s ignoring a very powerful feature of source control systems. Using branches is specially important when different developers or teams have to implement big features but still want to commit to the repo regularly. Using a branch they will not commit to the trunk and get in the way of other developers or affect the stability of the project (daily builds).
So, if you decide to go for branches the first thing I'd recommend is reading
Branching and Merging from the all almighty SVN book. It's a 10-20 minutes read and it gives you a nice overview.
Creating a branch is very simple, technically it's just a copy from one folder to another, so the command looks like this:
[code lang="bash"]svn copy http://myrepo.com/trunk http://myrepo.com/branches/SupreBranch -m "Creating branch for new super feature"[/code]
Please note that you can also branch a branch, not only the trunk. After you've created your new fancy branch just check it out somewhere and start making your changes, fixing ugly bugs and adding new features. The rest of the team will continue to work on the trunk (or their branches) and everybody happy.
Now, the big deal is
merging branches. SVN takes care of the heavy load, but most likely you are going to get some conflicts. That happens when SVN cannot make sense of the changes or decide which difference is more important. You can read
Branch Workflow from Jesse Warden's Agile Chronicles for a real case scenario.
A nice cool SVN feature is that you can get a little preview of what's going to happen before the actual merge. First let’s try this:
[code lang="bash"]svn merge --dry-run http://myrepo.com/trunk@42 http://myrepo.com/branches/SuperBranch@17 svn_trunk/ > changes.txt[/code]
See the --dry-run bit? That’s asking SVN: “Please tell me what would happen”. Then we pipe the result to a txt file for easier reading. The
@x means specific revision numbers to merge, btw. So now open your changes.txt file and you'll see what files are being deleted, updated, removed and more important, where the conflicts are (if any). Also note that you have to provide a valid working copy folder that will be used for the real merge (I prefer to use a clean trunk folder, but that's just my paranoia).
So, everything looks good? Even if it doesn't go ahead because nothing makes it to the repo until you commit, so here we go:
[code lang="bash"]svn merge http://myrepo.com/trunk@42 http://myrepo.com/branches/SuperBranch@17 svn_trunk/[/code]
Now in your "svn_trunk" folder you have the 2 branches merged. Wohooo! Go and take a look, resolve the conflicts and commit the local changes (the result of the merge) to the trunk and job done. Now you feel you have SVN super-powers or I at least I do.
There's much more stuff regarding branches like undoing changes, branching strategies, merging from the trunk to a branch or merging just some files, so again take a look to the
SVN Book and Google a little bit for more info.
Go branching, go!