<br><br><div><span class="gmail_quote">On 7/12/07, <b class="gmail_sendername">Brett Cannon</b> <<a href="mailto:brett@python.org">brett@python.org</a>> wrote:</span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I do know, though, that Thomas kept talking about moving us over to<br>Bazaar (or some distributed VCS) and instead of having a ton of svn<br>branches we have distributed VCS branch for each feature in Py3K.<br>That way the VCS's strong merge system would work in our favour for
<br>pulling in from the various Py3K branches and for eventual mainline<br>merging.</blockquote><div><br>No. I never talked about moving us over. I do not believe and have never believed that to be feasible (in the foreseeable future.) It is certainly possible to host a project of Python's size, depth of history and number of committers in a DVCS (Monotone is my personal favourite, with Mercurial and Bazaar a shared second), and certain things would go a _lot_ better with proper branch tracking and merging, but switching over Python means an entirely new way of working, educating all the developers and working around the limitations of the chosen system. (I'm not saying they have more limitations than Subversion per se, but we are already used to working around Subversion's limitations.)
<br></div><br>What I talked about was converting the monolithic p3yk branch to a collection of separate feature-branches, which would then be merged together into "the py3k branch", as well as the trunk (for backported changes.) The p3yk branch contains many changes that will never be backported, mixed in with change we want in Python
2.6. We currently do manual merging from the trunk into p3yk. When we start backporting features, those features in the trunk will end up conflicting with the p3yk changes. Worse, we will need to manually track bugfixes to those features in the p3yk branch in order to apply them to the trunk, and take extra care when merging in bugfixes from the trunk, too. Because Subversion don't keep track of which chunk was already merged, you get a lot of spurious conflicts. It gets extremely tedious to do those merges manually, and the error rate raises significantly. (I already have an uncomfortable feeling that I missed some of the merges in the p3yk branch, leaving bugs in p3yk that were fixed in the trunk. Fortunately, tests catch them fairly quickly -- but we still don't have 100% test coverage, not even for newly fixed bugs.)
<br><br>I have been working on converting the p3yk branch into separate Bazaar[*] branches, by first converting the whole branch (with 'tailor') and then applying each changeset to an appropriate feature branch, creating them as needed (using a little script based on tailor, because cherrypicking doesn't quite do what I want.) The last half year of changes, though, gets so incredibly intertwined that it's quite hard to pull them apart. Furthermore, I would still have to merge them back together to create the original py3k branch, and do merges with the trunk, too.
<br><br>I've been forced to decide it's not worth it, at this point. If we'd started with separate feature-branches earlier, it would have been. Now, it's easier and less error prone to just suck it up and deal with the numerous conflicts backported features will create. (Since I will be doing much backporting myself, I'm not just letting someone else deal with the mess :-)
<br><br>Some-branch-of-me'ly y'rs,<br><br></div>[*] Bazaar was chosen for a number of unimportant reasons that are entirely moot at this point. It doesn't reflect my personal preference or constitute any form of official endorsement :-)
<br>-- <br>Thomas Wouters <<a href="mailto:thomas@python.org">thomas@python.org</a>><br><br>Hi! I'm a .signature virus! copy me into your .signature file to help me spread!