title: Merging bug fixes into release branches - svn switch to branch or get a seperate working copy?
body: <p>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.</p>
  
  <p>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.</p>
  
  <p>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:</p>
  
  <ol>
  <li>Might be too easy to forget to svn switch back to the trunk after the merge.</li>
  <li>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.</li>
  </ol>
  
  <p>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.</p>
  
  <p>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!</p>