R. David Murray writes: > The workflow in svn "can" "require" this same thing: before committing, > you do an svn up and run the test suite.
No, it can't. That's not good enough, if you care about tree-wide consistency, because svn's approach has a race condition. You say you don't care, but for many, that was an artifact of svn's inability to enforce tree-wide up-to-dateness, and they don't want to go back (see Hrvoje's post). If you say that is *not* Python project policy, OK, neither Hrvoje nor I claim to determine policy. > That is, not only did the change in the tool and consequent change in > the workflow have *zero* impact on this aspect of the way I work with > CPython, it didn't even trigger me to *think* about it. That's too bad, because now there often is a better way. If you think you're ready to merge, then commit, merge, and run the tests *after* the merge. You still have an untested revision in the DAG, but it will not be tip. If the tests fail, update, lather, rinse, repeat. This won't be pleasant if people are sprinting and lots of commits are coming, because you're likely to repeatedly lose the push race. But in those conditions, nothing is guaranteed to work in decentralized fashion (that's one reason why the Linux kernel uses Linus and lieutenants as a serialization mechanism). _______________________________________________ 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
