David Abrahams wrote:
I just realized I can articulate what's not working for me about the current trunk/release branch arrangement.
* IIUC, there are always lots of failures on the trunk because there's no pressure to keep it clean.
that's always been the case.
* Before I check in a change in one of my libraries, I want to make sure I haven't broken anything else in boost. So naturally, I run the whole regression suite (there oughta be a better way!)
* But since the trunk is not clean, I spend a lot of time analyzing problems that have nothing to do with my library.
That has always been a problem for me.
That's a real disincentive to making changes in Boost. In fact, I am confident my low activity in the repo over the last year or so is primarily caused by the amount of labor associated with testing my changes.
Now, maybe you'll suggest that I test my own library, then damn the torpedoes and check in the changes, and let other people complain to me when their libraries break.
I believe that happens alot since there doesn't seem to be much alternative.
That would work... except that many people aren't paying attention to the health of their libraries on the trunk.
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. I have a boost release tree on my machine. The three directories relateded to the serialization library have been switched to the trunk. 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. Robert Ramey