svn dev cycle. howto lots minor "features" pending for approval.

Question

Hi I've read similar questions regarding that but still feel the need to ask a question. I have scenario where we have lots of tiny "features" pending for approval. I generally see two approaches.

1.Keep trunk solid and have tons of branches for each tiny "feature". Basically every new thingy is a branch.

Cons:
- Might become nightmare to support so many branches no matter how small a change. Keeping all branches in sync etc etc.
- Worst con I see in this is setup of test system so one can easily examine changes to approve (basically need to support all branches which seems insane).

Pros:
- Seemningly easy once approved a branch to be merged back to trunk and new release to be tagged and deployed.

2.For big features a branch is released and for small changes all goes in trunk(relatively stable) directly.

Pros:
- Easier to set test system as most of the time all will be directly visible. For big features should be easy to maintain separate branch on test.
Cons:
- Don't really see how release will go. I will not be able to basically release one part of trunk This would involve cherrypicking which is crazy to follow. Other approach is I just enforce that after some time (a week or so) all small features need to be approved so they can deployed before giving new tasks. I just create release branch and either all or none of small features are going live. This will be some fun discussion with head people.

I guess having lots of small pending stuff is very problematic to follow technically.

Answer 1

I use TFS, but the strategy would be same. Your option 1 is the cleanest approach but with merging overheads for many branches. It is good because your trunk in not polluted with untested code and new branches can be created from a stable codebase. You can also release each feature from its own branch for independent testing.
Another approach that may be applied if your changes are really minor and mutually independent (i.e doesn't affect the same source files) is to create a feature branch and then tag (label) each feature on that one branch. So you can get the labeled version for building and testing each feature. But periodically you have to get rid of this branch as more and more code gets changed.