Re: [boost] [SVN]Best Practices for developers using SVN

From: Peter Dimov (pdimov_at_[hidden])
Date: 2007-08-03 09:13:51

Martin Wille wrote:
> Vladimir Prus wrote:

>> A situation possible under proposed system is:
>>
>>         - You develop things on your branch. When your
>>         feature is ready, you merge from trunk. Suddenly
>>         half of tests in your library fails. The merge brought
>>         changes in about 100 different files, and you have
>>         to figure out what's up.
>>
>> With the current system, you'd get a failure whenever the problematic
>> change is checked in. So, you'll know what some commit between 1000
>> and 1010 broke your library and it's easy to find out the offending
>> commit from that.
>>
>> In other words, in the current system, if some other library breaks
>> yours, you find about that immediately, and can take action.
>
>
> "can" is the key word in the last sentence. Often enough, that didn't
> happen. Some change to some library broke some other library,
> unrecognized by the author of the change and not felt responsible for
> by the maintainer of the victim library. The regression persists until
> release preparation.

Consider what happens under the new system, though: the feature is blocked 
because an unrelated library doesn't like it. In the worst case, 
unmaintained libraries eventually block all progress on the stable branch. 
This is stable, but as bit more stable than needed.

No process can solve the problem of missing/unresponsive maintainers.

> A harder problem is adding of a new toolset. In that case, hundreds of
> test failures may pop up and nobody really feels responsible to look
> into them, ...

Another interesting example is adding a new test that exposes an existing 
bug. This test has never passed, but its inclusion is prevented by the 
stability requirement.