Boost logo

Boost :

Subject: Re: [boost] What Should we do About Boost.Test?
From: Robert Ramey (ramey_at_[hidden])
Date: 2012-09-19 13:10:38


Vicente J. Botet Escriba wrote:
> Le 19/09/12 08:08, Robert Ramey a écrit :

>> I urge anyone who doubts my position on this to try a simple
>> experiment.
> Don't misunderstand me. I have no doubts.
>>
>> a) Start with the release version of boost on your local machine.
>> b) switch your directories header and lib to the trunk via SVN
>> c) Run the bjam for your libraries
> d) do some modifications and test
> e) switch to trunk
> f) verify that everything is OK
> g) commit
>
> If you test using the release of the other libraries only, the trunk
> could be broken more easily.

I don't believe this.

I might believe that testing against the trunk might help detect
bugs in other developer's libraries. BUT as I've said before
this imposes huge costs on all the other developers and is
not efficient in any case. If a developer is depending on
the tests of everyone else's libraries to catch his own bugs
he should just write more tests.

> This is why I said that every author should use the same strategy.

I understand the point - I just disagree with it. It's a grossly
inefficient way to detect bugs and test software.

>>
>> It works great!
>>
>> And it's much faster since you only have to sync the release branch
>> once in a while rather than every day.

> I guess you will need to sync at least every time you commit, isn't it?

If you've got nothing else to do you could sync with the release everytime
you run tests. In theory you should be doing that now with the trunk
on your own machine. I know no one is doing that since it takes forever.

I practice - since the release branch changes much less frequently and
the interface on the release branch hardly ever changes, I just sync once
in a while - basically when boost emits a new release.

When you do sync, it's much faster since the release branch changes
a lot less.

Robert Ramey


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk