To answer the obvious question up-front: yes, I'm very aware that Git is hott: proof . In fact, I'm using it to manage my pet soon-to-be-open-source project that I'll announce soon. But we're using Subversion at work, and honestly, I'm a little afraid of trying to migrate a whole company to a new version control system when the current system works fine for most cases and those less technically inclined among us would have a bit of a learning curve.

To make a long story shorter, I am working on a project to add features and integrate new design elements into an existing site, and there are occasional updates that need to get pushed up to the live system. Because of our rotating support schedule, I don't want to commit my changes to the project's trunk: that would chance another developer making a maintenance update and deploying the site (via a Capistrano task). But I obviously need to commit them, so I need a new branch for the project (this is the most common use case that I'm aware of for branches). I'd been under the impression that SVN's branching and merging capabilities were really difficult to use and understand, so I've been putting off learning to do this (and a few times committed the cardinal sin of NOT CHECKING IN).

It wasn't as bad as I thought, even though I was starting off in kind of a weird position: my working copy (of the trunk) had local changes, from where I'd started on the time-consuming updates before realizing I really needed a branch. Here are the steps I took (of course, as with most problems, there are many ways...):

1. Create a branch at the repository, where http://svnrepo.com/path/to/repo is the URL to the repository root:
   svn copy http://svnrepo.com/path/to/repo/trunk http://svnrepo.com/path/to/repo/branches/crazy-new-branch -m "creating crazy new branch"
2. Change the working copy's SVN metadata to refer to the new branch rather than the trunk:
   svn switch http://svnrepo.com/path/to/repo/branches/crazy-new-branch

At this point, I was ready to roll and could svn ci and do other operations as normal, without fear of changes to the trunk.

The next (and final) test was merging those changes back into the trunk, which also ended up working great (I'm not sure to what extent strange problems can arise, but my merges have gone flawlessly so far):

1. Get the revision number where the branch was created (write it down if you are forgetful like me!):
   svn log --stop-on-copy http://svnrepo.com/path/to/repo/branches/crazy-new-branch
   Let's say it was revision number 264.
2. Check out the trunk (in a different location than your working copy of the branch):
   svn co http://svnrepo.com/path/to/repo/trunk projectname_trunk
3. Get into your new working copy of the trunk (the pathname will vary according to where you are in your directory structure, of course):
   cd projectname_trunk
4. Get the trunk's current revision number:
   svn info .
   Let's say it was revision number 286.
5. Merge the branch into your working copy of the trunk:
   svn merge -r 264:HEAD http://svnrepo.com/path/to/repo/branches/crazy-new-branch
6. Fix conflicts as required and push your working copy (of the trunk) back to the repository's trunk:
   svn ci -m "merging crazy new branch changes back into trunk (264:286)
7. Rejoice that things work OK and you don't have to migrate your whole company to a new version control system!