[Python-Dev] I am now lost - committed, pulled, merged, what is "collapse"?

[Stephen J. Turnbull]

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