RE: Re: Troubled by a strategy that has developers creating feature branches from latest release rather than trunk
Date: Tue, 17 Mar 2009 11:26:24 -0700 (PDT)
> (I am deliberately top-posting.)
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:
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.
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
This is an archived mail posted to the Subversion Users mailing list.