Commit Vs Merge

We have to create a special interim alpha release for our product which should consist of only a select set of features. This set of features are also required in trunk for our main release.

My feel is branch from trunk for the interim release and to make frequent merges of the stable branch to trunk so that we are in sync. However there is a second school of thought that we commit into both places and also merge the branch finally.

开发者_开发技巧
1. Here are couple of things which I feel would be problematic in the second approach. As we would have the changes in both places, merge would create problems later on. (for any missed commits)
2. Any bugs created by the commits would destabilize trunk too. This can be avoided if we merge stable branches.
3. Overhead for the developer to commit it in to trunk too. (need a working copy, need a second commit)

My question is, can you let me know more positives and negatives of both these approaches ?

A lot of people call this a "feature branch". You can split off of trunk, implement a bunch of new stuff in your new branch, then merge it back to trunk when you are done. If you are using svn or anything modern, the merge abilities are pretty stable. This means you can make other releases from trunk that do not contain this new code until you are finished with it.

I prefer to make a primary commit only once, and merge it to other branches when needed. I think this makes for a much cleaner codebase.

If you need the new branch's changes earlier, you can always do interim merges at various points, such as after a new feature is tested by QA. This way you can control how stable both branches are.

As I have not received any significant reasoning for both the approaches. I am answering my own question. I would go with the merge approach as per the benefits stated in my question itself.