Merging bug fixes into release branches - svn switch to branch or get a seperate working copy?

Question

I'm relatively new to Subversion, hoping to get some insights from more experienced folks. We're taking an approach of doing the bulk of the development work (new features and bug fixes) on the trunk and merging bug fixes into release branches as needed. With this approach, developers won't be coding directly against release branches at all, only merging into them.

My first thought was that maybe developers don't need a working copy of the release branches at all, and maybe changes to the trunk could be merged into branches directly in the repository. But I quickly learned that that's not how Subversion works - you need a working copy to merge into.

So my next thought was that developers could still keep just one copy of the codebase locally, point it to the trunk, and do an svn switch to a release branch when they need to do a merge. A couple potential problems I could forsee:

1. Might be too easy to forget to svn switch back to the trunk after the merge.
2. A developer could have uncommitted changes to their working copy (something they were working on for a future release before they got interrupted to work on the bug fix) that would still be there when they do the svn switch, and accidentally merge those changes into the release branch.

If I put together some scripts for this process I could prevent #1 from being an issue, but #2 concerns me a little more. I'm wondering if that's a deal-breaker for this approach.

In a nutshell, my question is this: when merging bug fixes from the trunk to a release branch, where the developer does not already have a working copy of the release branch, is it considered a better practice for the developer to do an svn switch to do the merge, or to check out a working copy of the release branch in a different location locally? Thanks in advance!

Answer 1

Disk space is generally cheap nowadays, so there's not really a reason to confine things all to a single working copy - checking out the branch separately gives the best of most worlds (independent of trunk development, less chance to forget where one is, can easily swap back and forth from working on branch to working on trunk if necessary, don't have to re-download trunk when done).

Answer 2

That's a rather philosophical question. To avoid problem #2 I would probably go with a separate checkout for merging. It may take little longer that way but it is definitely more flexible.

Answer 3

I would avoid using svn switch except in the occasional circumstance (as described in the docs) when you start coding a solution against one branch (say trunk) and then conclude that it would be better in its own branch (svn copy trunk newbranch; svn switch newbranch).

You should always perform merges into a local working copy, both so you can perform a diff on your changes before you commit them (which you should be in the habit of always doing before a commit, any commit) and also check that the code compiles.

If the release branch is large and it is cumbersome to keep a local working copy of it (which can especially be the case if you have many release branches on the go), then consider using a branch/patch manager - designate one of your senior programmers to manage the release branches and he/she can select particular trunk changes to merge to the release branch(es). Most people are saved the hit to their disk usage, and you keep the stable release branches under more control.

Answer 4

I use SVN's sparse checkout feature a lot. If I check out a repository I check out the trunk/tags/releases folders non-recursively (immediate children, including folders). I then go into each of them and update so that their immediate children are checked out, too. That way I have a full overview of the whole repository without wasting too much disk space.

Then I go and update fully recursively whatever I want to work on. If I'm done with something that isn't to be deleted in the repository, but which I won't need on my disk anymore, I just update it to immediate children again.

This has the obvious advantage of mirroring the actual layout of the repository on your disk. It's easy to navigate to some branch that way. Another advantage of this approach is that a simple update will tell you about new tags and branches.

I have yet to come across a repository where the number of tags or branches is so enormously overwhelming, that just checking out the folders non-recursively waste space.