s...@pobox.com writes: > > Stephen> This won't be pleasant if people are sprinting and lots of > Stephen> commits are coming, because you're likely to repeatedly lose > Stephen> the push race. But in those conditions, nothing is guaranteed > Stephen> to work in decentralized fashion (that's one reason why the > Stephen> Linux kernel uses Linus and lieutenants as a serialization > Stephen> mechanism). > > So DVCS scales up to a point, then it breaks and you need to revert to some > sort of serialization scheme?
No, software engineering scales up to a point, then it breaks and you need a serialization scheme. The problem is not the DVCS, it's the demand for a *centralized*, authoritative, safe, stable version. DVCS can scale at least to Linux kernel pace if you only ask for centralized authoritative.<wink> DVCS is "No Silver Bullet", it only helps with some accidental costs of development. It doesn't help with the costs of review and testing. There are in fact problems with the current generation of DVCSes. Lack of plists on commits, for example. You'd like to have a "tested" property, in fact two of them (one for the committer, one for the buildbots). You'd like to have a "checkpoint" property, which commits would by default be ignored by "log" and "bisect". You'd like to have an "issues" property, a list of issues applicable to this commit. But again, these would only reduce accidental costs. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
