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

From: Martin Wille (mw8329_at_[hidden])
Date: 2007-08-03 10:18:41

Peter Dimov wrote:
> 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.

True, this is a problem.

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

The scenario you described would indicate that it is time  to deprecate
the unmaintained library. There's no way to promise stability for
unmaintained code. Once deprecation is part of the process, the problem
does get solved. Quite slowly so, I admit.

>> 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.

No, in this scenario, the bug has been there before. There's no break of
stability if the bug gets indicated by the testing harness from some
point in time on.

Regards,
m