Best practices for source control and bug fixes

Question

If we need to issue a bug patch that does not include current development that has been committed, or any changes from their current version, what should be done to make the process safer and with lower overhead?

We are currently using Subversion for our source control in a small (3 developers) team primarily developing in Visual Studio 2008. We anticipate that the team may group to 8 developers over the next year, and for any previous release support to become more complicated. While most customers are on the current release, some are further behind.

Answer 1

Source control can handle this pretty easily, and was designed for this.

When you reach the stabilization period of your release a branch should be done. It is important that you do not start any work on the next release before this is done.

Any bug fixes for that release should be done in that branch. This prevents new code from an upcoming release from polluting the bug fix. Once the bug fix is done then you can merge that change down to the trunk, and any other releases as necessary.

Don't forget to put the bug number in the comment, as this will make keeping track of commits easier.

Answer 2

How about: a branch per major version, with bug fixes applied to the branch(es) as needed, and also applied (or merged) back to trunk.

Answer 3

Where I work, we have several projects working simultaneously. In order to avoid this issue, we have several variants of the source code. For example, the first release is Variant 1.0. We create a branch off of this release, say, Variant 2.0, for all future development. If we need to do a bug fix, we do it on the main Variant, which is currently 1.0 and can release that. When Variant 2.0 is ready to go to production, we merge it with whatever is on the main branch (in this case, 1.1) and that becomes the new main trunk. At one point, we had 4 branches running at the same time.

Merging the code can be time consuming, and you have to be careful not to introduce new bugs during the merge, but if you have a decent code comparison tool available, then it shouldn't be too bad. We did a merge a while back using Beyond Compare on a 10,000 file source directory, and it took a single morning.