Re: [boost] [1.36.0] Libraries with unmerged changes?

From: Robert Ramey (ramey_at_[hidden])
Date: 2008-07-17 13:22:20

Ilya Sokolov wrote:
> Robert Ramey wrote:
>> [snip]
>>
>> I envision the following:
>>
>> a) a "release ready" version branch or whatever.  This version pass
>> all tests or failing tests are marked up - its "perfect" (lol)
>>
>> b) I make a change in my library, and test against the "release
>> ready" version.
>
> It is not clear to me who will test 'against the "release ready"
> version', you or testers? If testers, than you need one tester for
> each library and I don't believe boost have such resources.

OK - now we're moving beyond discussing the merit of the idea
to discussion its praticality - a whole new discussion.

Of course I'm game.

On my own system there's no problem.  I just have a "release ready"
boost and run the tests on the compilers that I have.  The issue
is when I want to see tests run on other compilers.  I would
imagine a process similar to the following:

a) I upload to the trunk.  A tester runs his script.  Currently
the test script which syncronises his local system with the
trunk and runs the bjam tests. In my proposal, the tester
would maintain a "release ready version" on his machine.
The script would do the following:

a)  determine which libraries have changed since the last
time he tested.

b) For each changed library:

i) the equivalent of the SVN "switch" command would be
invoked to sync up THAT library with the trunk.

ii) bjam test script would be run for only that library.

iii) After the test, SVN switch would be reversed.

This would entail a lot less.  Since one small change in
a common header wouldn't trigger testing all the libraries.

Futhermore - the testing could, and should be a lot more
exhaustive than it is now.  Here is a plug for my library_status
program which produces a table for a library which includes
ALL build configurations - not just debug with dynamic libraries.
See www.rrsd.com (boost) for an example of the output this
program produces.  This helps address the problem where
I test for debug - only but the program turns out to fail in
release or some other build.  This has been he source of
much frustration with the serialization library.

Now second phase.  The release manager gives me permission
to roll in my changes into the "release ready" branch.  The testing
is identical to the current system - there is no "SVN switch".

The tester signs up for either trunk testing or for release
testing - which is what he does now.

In short, implementing this would require a different and more
intricate trunk testing script.  This is simple to state and to
describe - but would in practice be somewhat tricky due
to the following:

a) Library code not found in one directory so doing an
SVN "switch" is not just a one liner.

b) I seems to me that an SVN switch in fact does a
merger - which can lead to conflicts.  And switching
back might result in a change in the library.

I suspect these issue could be addressed by more
careful investigation of the details of SVN usage.

So that is more or less how I would envision this
testing program being implemented.

Robert Ramey