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:
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!
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).
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With