Managing branches in subversion

问题:

I don't think I'm doing something right. I am using subversion as my vcs for our organizations website. I am the sole developer and I'm using bugzilla as my bugtracking system. I've got bugzilla and svn loosely coupled using the bugtraq properties so that I can link from my comments to bugzilla. What I'm doing right now is whenever I get a request to perform any work on the website (enhancement, breakfix, content change) I create a bug [xx] in bugzilla then create a branch named bug[xx]. After I complete the task I manually export the branch changes to our beta site, the change is reviewed and verified then I merge the branch back into trunk indicating the bug# using the bugtraq property.

This works pretty well Except when I have more than one or two changes. If I created 10 branches for ten work requests I want to know how to easily tell which ones are already merged into trunk, and which ones aren't. If I'm supposed to use the mergeinfo property that seems crazy...

I'm not wanting to switch from subversion, so don't suggest it.

回答1:

Why don't you just delete the branch when it has been reintegrated into the trunk? That what you're supposed to do (in the general case) when a feature branch has been reintegrated. So the diagnostic is simple : if the branch exists, it hasn't been reintegrated.

回答2:

Your workflow seems pretty good to me. However, after you merge back to trunk, you no longer need the bug branch, so delete it. That way, you will only ever have the number of branches as opened bugs.

You can always get the branch back if you need to, but it won't clutter things up.

回答3:

Creating a branch for each bug is not a good practice from my point of view. As branching best practices mentions, you should create branches in two cases:

1. When you are developing a new feature that may take a long time (feature branch) and
2. When you want to keep your last released version (Release Branch).

It seems that you just need the second branch. To make it clearer take a look at the picture below:

The development branch is the one that is kept under your trunk directory (the green line). You can create a branch called the release branch (the red line) and merge the changes you want to release into it. This way, only the selected changes come into your released version. If you are developing a new feature that may take you more than 1-2 weeks, create a feature branch (the blue line) and merge back the changes when you finish. The feature branches may be deleted when they are done.

So, I propose you to have just one branch called the release branch. When you receive a bug, make the changes in your development line. When the testing is OK, you can merge the changes back to the release line. This way, you can release just those features that you want. In addition, by taking a look at your release line history, you can find which changes has been merged into your release line.