A question on Feature/Task branches when using Subversion

Question

I have come across sources that say that it is better to have separate branches for different features than implementing the feature in trunk.

A question that I have with this approach is, when merging a feature to trunk, we will be merging the whole thing at once. If we do this and annotate a file to see the reasons behind different lines of code, we would see a comment saying "merging xyz feature" which would not be very helpful.

Is there a way to overcome this issue?

Answer 1

If your problem is that when using SVN Blame (aka Annotate) it doesn't show you a list of all the commit comments for merged revisions?

If so, you need to add the -g flag to the command, or if using TortoiseSVN, check the 'Include Merge Info' checkbox.

Answer 2

There are sources that would say that, but there are also sources that say that the earth is flat.

Task branching in a distributed vcs is workable, though something of a solution in search of a problem in the vast majority of cases. In previous generations of systems, it will be pure pain for no gain. It won't do anything useful; and if (when) you get it wrong it will cause confusion and unnecessary rework.

In the worst case your task branches become stealth feature branches. And then you end up maintaining several times the volume of code you need to; every other team member has there own private slightly-different versions of common libraries representing work in progress. Meaning every merge breaks things, so merges happen less, so every branch diverges more.

That's the kind of thing you might have to do, the kind of costs you might have to bear, if you had multiple customers with incompatible needs, or tortuous legal restrictions. Except you are doing it to your own team, for no reason other than a vague feeling it's the right thing to do.