[Python-Dev] Subversion branch merging

[Thomas Wouters]

On 7/12/07, Brett Cannon <brett at python.org> wrote:

> I do know, though, that Thomas kept talking about moving us over to
> Bazaar (or some distributed VCS) and instead of having a ton of svn
> branches we have distributed VCS branch for each feature in Py3K.
> That way the VCS's strong merge system would work in our favour for
> pulling in from the various Py3K branches and for eventual mainline
> merging.


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.)

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.)

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.

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 :-)

Some-branch-of-me'ly y'rs,

[*] 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 :-)
-- 
Thomas Wouters <thomas at python.org>

Hi! I'm a .signature virus! copy me into your .signature file to help me
spread!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-dev/attachments/20070713/df822a5a/attachment.htm