Multiple feature development branch in subversion

G'day,

Can the following strategy be implemented with subversion?

1. A stable trunk that holds the production version of an application
2. A separate development branch that holds multiple features
3. Keep the development branch in synch with the stable trunk
4. Merge/copy individual features from the development branch to the trunk as they become production-ready

The reason for wanting 2. is that we also need an "early release" build that holds all the features currently in development.

The standard feature branch pattern doesn't suffice. The branch holds a single feature and should be deleted once the feature is merged into the stable trunk. I've read that you can continue to use a branch after a merge --reintegrate but it's not re开发者_高级运维commended.

I was wondering whether (file system) copying individual features from the development branch to a working copy of the trunk (build, test, commit, then immediately synch the branch with the trunk) would be possible? The synch would result in conflicts but easily resolved ones.

Thanks,

Chris.

You can make as many branches as you want, there's nothing special about the names "trunk" and "feature". In your case I'd say make several feature branches, perhaps named after the feature ticket item in your tracker.

Yes, your strategy can be implemented with subversion. But it will be quite inefficient since you will have to list all the commits (or commit ranges) related to the feature being merged, in the the merge command.

A much better strategy is with single feature branches. You can have as many branches as you want and merge them at any time individually. And you don't have to list the commits when doing so since you typically will merge the whole set of changes of each branch.

People often argue that branching is to be avoided because of the difficulty to merge back. But cherry-picking from a multiple feature branch is even more unpleasing.