All code added to the code base has to be integrated with all other
code, even code that "does not affect me". Actually, how do I know that
another devs code doesn't affect me unless I integrate what they did,
build and test?
They could provide a similar isolation by using a Stable branch which a
release manager/integrator merges into from trunk once the revision has
been unit tested. Then system testing can be done from the stable
branch. But, this still allows for all new dev to work in branch with a
fully integrated build/test process.
Another option is for each dev to be sure to merge from trunk to ensure
that they are integrating other devs code and there are no breaking
changes. This is similar to what they are prosing. But, to have every
dev working on their own branch oblivious to the rest of the project
sounds like not the best idea. The theory of agile is integrate often so
you are still close to the problem. Because you will have API and other
conflicts... but if you want until a month down the road or whatever to
integrate it is going to be more painfull. And this integrator guy is
going to have mucho problems since he isn't the guy that wrote the two
bits of code in question.
You might want to look at "feature" branches. It is similar also to what
they are proposing... but once again it expects that branch checkins are
merged into the feature to ensure ongoing conflicts are resolved... the
idea being that when the feature branch is integrated back into trunk
the trunk will still build and pass all tests.
Anyway... just some thoughts. Hope it helps.
> -----Original Message-----
> From: webpost_at_tigris.org [mailto:webpost_at_tigris.org]
> Sent: Tuesday, March 17, 2009 2:26 PM
> To: users_at_subversion.tigris.org
> Subject: 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
> > that be?!) but I think you have valid concerns. Basically, I think
> > 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
> > worries?
> A bit of both... I did speak up in the group context in which the
> was presented, and I argued until I was blue in the face with one of
> 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
> that the trunk was less stable than the latest release; i.e., pre-
> integration unit testing notwithstanding, it is possible for bugs to
> into the trunk. The desire is to insulate other developers from such
> I see several problems with this line of reasoning...
> Most changes integrated into the trunk will *not* be de-stabilizing:
> a destabilizing trunk change should be the exception rather than the
> (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
> never should have been integrated, there will be many times when
> to take valid trunk changes into account will force much rework by the
> various developers, not to mention nightmarish merges by an integrator
> didn't author any of the code being merged.
> As I see it, from an individual developer standpoint, there are
> 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
> into account as early as possible: failing to do so before making my
> feature change and performing pre-integration testing can lead to a
> optimal or incorrect implementation, and can decrease the utility of
> 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
> safest strategy would be to start with all of them.
> As for the case in which a de-stabilizing change happens to slip into
> 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
> formal release. In an ideal world, such issues would always be caught
> during post-integration testing, but isn't it preferable to catch them
> It seems to me that the proposed approach could make for difficult
> 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
> 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
> integrator attempts to merge. This conflict, however, was completely
> At any rate, hopefully, I'll be able to convince the group before they
> too far down the road with this. I really appreciate your response.
> Brett Stahlman
> To unsubscribe from this discussion, e-mail: [users-
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-03-17 20:13:01 CET