s...@pobox.com writes: > Stephen> interactions across modules. That is, it's not that Subversion > Stephen> provided a simpler way of doing the work. Rather, it hid the > Stephen> fact that certain work was not being done at all. hg exposes > Stephen> this fact.
> Can you provide an example of this (real or hypothetical)? What happened to you is a real example. With svn it would go through, and any problems would be caught later. With hg, it doesn't. This is basically the statistical idea of false positives vs. false negatives. svn tends to generate false negatives (tests don't fail until after the merge), while hg tends to generate false positives (merges fail because they aren't "fast-forwards"). > It seems to me that if all you have is unit tests it matters > little, if at all, whether you catch test failures before a checkin > (in your local hg repo) or after (using svn + a buildbot run). In the long run, that's right. In the short run the choice is between imposing a substantially higher burden of merging and testing on individual developers in order to get a higher quality shared branches versus imposing a detectably higher burden on the project as whole in terms of red buildbots. It clearly matters to the individual developers, and core developers are likely to have different interests here from the occasional committers. The burden on the project could get *very* high; that's why the Linux kernel went to Bitkeeper, then git, rather than Subversion. It was necessary to impose as much burden on the branches as possible before merging to trunk. But then, Python doesn't have anywhere near the change rate that the kernel does (Lennart R's woes notwithstanding). I'm not going to take a position on what's best for the Python project; I've drunk the DVCS Kool-Aid and am very much in Jesus's "let's work with the tools, not against them" camp. But there's an uncertain amoung of bias in that opinion, and I'm not a committer so can't speak from experience with the Python workflow. > The workflow of the version control system isn't going to magically > expose semantic interactions across modules. It seems to me that > at best the new workflow means there is a better chance of catching > textual conflicts before checkin than before. No, at best the DVCS workflow forces the developer on a branch to merge and test the revisions that will actually be added to the repository, and perhaps notice system-level anomolies before pushing. Whether that is significant in practice is as yet a matter of faith for me. But again that's a personal opinion, not yet a recommendation for the project. _______________________________________________ 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
