Randomness for you since 1976
UPDATE: Don’t follow this guide, look down in the comments and do what John suggested. This totally screwed me up, as none of the changes I did before I created the branch came through in the merge.
I started working on a new feature for my product today, and realized after several hours that committing my code would be a bad idea. The new feature is big enought that I should have started working on it in a branch, but I didn’t think of that early enough. I thought there would be a simple way to “commit changes to a new branch”, but I wasn’t able to find any obvious way to do that. Here are the steps I took to get this accomplished.
From trunk checkout with uncommitted files:
That’s all there is to it. If you know an easier way to do this, let me know. I wonder if I had done the “svn add” commands before the switch if that step would have been unnecessary.
This blog is a dumping grounds for my experiences as a web developer, a parent, an artist, a writer and a human being. Maybe someday there will be something here that is worth your time, some sort of useful information or words that piece your very soul. Probably not though.
John
August 21st, 2008 at 4:40 pm
This is reasonably close, but not quite right.. Also, instead of doing an svn cp on your local working copy you’re better off doing it against the server. The form of the command is the same, but you’re using urls for the source and endpoint.
It should look something like:
1. Create your branch with: svn cp http://server/project/trunk http://server/project/branches/branch_o_doom -m “Creating my branch to take over the world”
2. Move your working copy to the branch: svn switch http://server/project/branches/branch_o_doom
3. Do your work.. update from the repo, modify files, add files, check in, etc as usual
Now for merging your branch back to trunk you need to figure out what file range needs to be merged, then merge it back. Svn won’t do merges on the server itself (for good reason) so you usually do this against another local working copy.
1. Find out the revision range on the branch: svn log –stop-on-copy http://server/project/branches/branch_o_doom
It’ll give you a log of all the commits on the branch, stopping on the initial copy that created it. Note that revision number.
2. Checkout trunk (or cd to it, whatever): svn co http://server/project/trunk
3. Merge it! (this is against a checkout of trunk): svn merge -r 7424:HEAD http://server/project/branches/branch_o_doom
4. Sanity check what it did.
5. Commit it back to trunk (note that its good form to notate the rev range you’re merging): svn ci -m “Merging branch_o_doom to trunk r7424:r:7535″
F. Morgan Whitney
August 22nd, 2008 at 7:20 am
My svn copy actually seemed to copy form the trunk in the repo and not my checked out copy, as non of the new or modified files appeared in the new branch, so I wonder if . or the trunk URL really matters. I did use a URL for the branch in my actual implementation.
Another tip for anyone who stumbles across this, to find the revision number from when you created your branch, you can use:
svn log –stop-on-copy
This article has a fairly straight forward step by step for merging your branches into your trunk:
http://www.sepcot.com/blog/2007/04/SVN-Merge-Branch-Trunk
Peter Williams
August 25th, 2008 at 9:31 am
If you want to do feature branching like this you should definitely consider switching to Git, Mercurial or Bazaar. They make this sort of thing dead simple. Oh, and they make just about everything else about source control easier too.
F. Morgan Whitney
September 3rd, 2008 at 11:50 am
In case anyone is keeping score, this totally didn’t work. Do what John said