RE: Re: Troubled by a strategy that has developers creating feature branches from latest release rather than trunk

> (I am deliberately top-posting.)
>
> I am not an svn expert, nor have I sent code into space (how cool would
> that be?!) but I think you have valid concerns. Basically, I think your
> team should have a very good reason for not doing things "the usual
> way". Have you presented your concerns to the team? What answers did
> they have? Or are you gathering your ammunition before presenting your
> worries?

A bit of both... I did speak up in the group context in which the proposal was presented, and I argued until I was blue in the face with one of the plan proponents after the meeting had adjourned. The problem is that, because there are no recognized Subversion experts in our group, my opinion carries no more weight than that of one who hasn't read the applicable portions of the manual.

As for the "why" behind the proposed strategy, the only reason given was that the trunk was less stable than the latest release; i.e., pre-integration unit testing notwithstanding, it is possible for bugs to creep into the trunk. The desire is to insulate other developers from such bugs. I see several problems with this line of reasoning...

Most changes integrated into the trunk will *not* be de-stabilizing: i.e., a destabilizing trunk change should be the exception rather than the rule. (If this is not the case, we might as well cancel the project now. ;-) That being the case, the proposed strategy seems to be designed to optimize the exception at the expense of the rule. In other words, for every one time that developers are inconvenienced by a trunk change that never should have been integrated, there will be many times when failing to take valid trunk changes into account will force much rework by the various developers, not to mention nightmarish merges by an integrator who didn't author any of the code being merged.

As I see it, from an individual developer standpoint, there are basically two types of trunk changes:
        1) those that affect me
        2) those that don't
It seems to me that in the first case, it behooves me to take the changes into account as early as possible: failing to do so before making my feature change and performing pre-integration testing can lead to a sub-optimal or incorrect implementation, and can decrease the utility of the pre-integration tests I perform. Since I don't always know in advance which trunk changes will affect me and which will not, the simplest and safest strategy would be to start with all of them.

As for the case in which a de-stabilizing change happens to slip into the trunk, it seems to me that temporary inconvenience to one or more developers is a small price to pay for increasing the probability of finding the bug before the next release. I have worked on a project in which bugs introduced by merges performed by the integrator made it into a formal release. In an ideal world, such issues would always be caught during post-integration testing, but isn't it preferable to catch them earlier?

It seems to me that the proposed approach could make for difficult merges, even in the normally trivial case of non-overlapping feature changes. Consider the case in which developer A tests a new feature and has it integrated into the trunk. Developer B then creates a feature branch to implement his own feature. If Developer B creates his branch from the trunk, there can be no conflict, but if he creates it from the latest release, the changes from Developers A and B could be conflicting when the integrator attempts to merge. This conflict, however, was completely avoidable.

At any rate, hopefully, I'll be able to convince the group before they get too far down the road with this. I really appreciate your response.

Brett Stahlman

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1342660

To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-03-17 19:30:14 CET