webpost_at_tigris.org wrote:
>> (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.
>
Depending on the type of code you are writing, trunk changes of the
first kind might be scarce. I write electronic design automation (EDA)
software, which is characterized by a long sequence of non-linear,
discontinuous optimizations. If I were trying to develop a new
optimization algorithm (which might take weeks) to be run late in the
sequence, tracking trunk updates on a daily basis would introduce an
unacceptable level of noise into my analyses due to changes in
optimizations earlier in the sequence. A feature branch is very useful
for this kind of scenario. Even then, I think a feature branch from
trunk would be better than a feature branch from a previous release.
Your mileage may vary; I don't know what type of code forms the majority
of your project.
> 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?
>
Look at it from his perspective: it's a series of small annoyances
("why doesn't trunk build this morning?!??") vs. one big annoyance at
merge time. If the small annoyances are relatively frequent, then a big
merge starts to look like less trouble. (I'm not arguing for his
perspective, just pointing it out.)
If your code is very cleanly partitioned, such that most development
occurs in isolated areas of code which use a stable suite of core
modules, then you might be able to get away with branching from a prior
release and doing one big merge to trunk at the end. But that's a big
"if." As soon as a developer needs a change to that core suite for
his/her feature branch, merge problems become much more likely (and
troublesome).
> 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.
>
I don't follow this argument; if they are non-overlapping then how would
they conflict? Are you assuming, for example, use of core code that has
changed since the last stable release?
--
David Chapman dcchapman_at_acm.org
Chapman Consulting -- San Jose, CA
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1343012
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-03-17 20:26:41 CET