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.
BOb
> -----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
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&dsMessageI
d=
> 1342660
>
> To unsubscribe from this discussion, e-mail: [users-
> unsubscribe_at_subversion.tigris.org].
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1342949
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-03-17 20:13:01 CET