Re: [boost] Why the integration branchmust remain clean, etc.

Subject: Re: [boost] Why the integration branchmust remain clean, etc.
From: David Abrahams (dave_at_[hidden])
Date: 2009-06-12 12:18:44

on Mon Jun 08 2009, "Robert Ramey" <ramey-AT-rrsd.com> wrote:

> David Abrahams wrote:
>
>> I suppose another approach might be to test against the release
>> branch, then svn switch to the trunk and check in my changes there.
>
> This has worked very well form me.
>
>> But that is still laborious.
>
> And it's not laborious at all.  

It is.  You're suggesting something else:

> I have a boost release tree on my machine.
> The three directories relateded to the serialization library have been
> switched to the trunk.  

I was talking about switching the whole tree over to trunk just before
checkin (and testing again to make sure you're not breaking anything
there).

Your approach works pretty well until you find an issue in some utility
outside your own library --- say, it needs a workaround for a compiler
you're testing against --- and you have to make a tweak there.  You risk
checking that tweak in on the release branch.  Also, I'm responsible for
more diverse areas of the Boost SVN tree than you are, so it might get
hard to keep track of which parts are switched.

Also there's a good chance of breaking something in the trunk because
you haven't tested against that code.  Hmm, a clean compile against the
trunk is supposed to be a prerequisite for a merge to release, but not
testing against the trunk might be a gamble worth taking if that
breakage is rare enough.  Seems like this approach could contribute a
little to making the trunk more broken overall, though, and we both
agree that brokenness on trunk is a problem.

> I run serialization libraries tests on my own machine with no problem.
> No extra effort is required to know that all errors are due to my own
> local changes.  There are no "hidden variables" or "side effects".  It
> has saved me huge amounts of wasted effort.
>
>> I'm not sure what to do about this, but it's really killin' me.
>
> Take my advice.

I'll try it, but I'm worried that it's more viable for you than it is
for me for some of the reasons I cited above.

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com