Please help Python team decide on a VCS

[Martin Pool]

On Fri, Nov 28, 2008 at 1:37 PM, Barry Warsaw <barry at canonical.com> wrote:
> I am shepherding the Bazaar effort, so clearly I suck.  I've just been
> swamped with other things.  I'm keen on having Bazaar chosen though so I
> would welcome any help in making its case.  You can contact me directly if
> you have any information you'd like to add to the PEP and can't do so
> directly (I can also try to get you access to the document).

We can help you suck less :-)

Here are some answers to the unanswered scenarios; please add them in,
or forward it to someone who can.

As a preliminary, people should make a 'repository directory'
containing all their work on each project on their laptop/desktop
machine, eg

  bzr init-repo --1.9 ~/python

> bzr diff -r submit: > __patch__

It's better as
  bzr send -o __patch__

>     * Branch off of trunk.
>     * Apply patch w/o any comments as generated by the patch submitter.
>     * Push patch to server.
>     * Delete now-useless branch.

So, basically:

  bzr branch trunk integrate-bug1234
  cd bug-1234
  bzr merge < __patch__
  bzr status     # this shows the pending merges too
  bzr diff |less
  ... generally inspect, test, and examine the merged changes
  ... if you're happy:
  bzr ci -m "merge patch for bug 1234"
  bzr push bzr+ssh://bzr.python.org/trunk

> Python always has at least the trunk and the last major release to potentially backport patches to.

We'd generally recommend doing the fix first in the oldest supported
branch, and then merging it forward to the later releases.  In this
case it's just:

  cd python-2.5-1300
  ... make fix
  bzr ci --fixes python:1300 -m "fix bug 1300"
  cd ../
  bzr branch python-2.6 python-2.6-1300
  cd python-2.6-1300
  bzr merge ../python-2.5-1300
  bzr ci -m "merge bug 1300 fix from 2.5"

and iterate this process of merging the changes from one branch to the
next.  After each release is made from an earlier release, you'll need
to do a merge that makes sure the NEWS, version number, and similar
things are resolved properly.

If you do want to cherrypick just the last change from a later version, it's

  cd python-2.5
  bzr merge -c -1 ../python2.6
  ... check the result
  bzr ci -m "merge back"

or with "-r a..b" to merge a range of revisions.

> Sometimes core developers end up working on a major feature with several developers. This requires creating a branch on a server that other developers can access.

>    * Branch trunk.
>    * Pull from branch on the server.
>    * Pull from trunk.
>    * Push merge to trunk.

The branch/repository URLs given to any bzr command can be remote,
over ssh, sftp, http, ftp, etc.  So:

  bzr branch bzr+ssh://bzr.python.org/{trunk,hotttness}
  # now copy it to your local machine
  bzr branch bzr+ssh://bzr.python.org/hotttness
  # pull changes from parent branch
  bzr pull
  # push back changes, or error if there are new changes needing to be merged
  bzr push

>   Separation of Issue Dependencies

There are a few tools for dealing with this kind of situation.

(1) bzr shelve allow storing uncommitted pending changes into the
working directory, to let you reduce your changes down to just what's
needed, commit that, and then resume your previous work.

  bzr shelve

mbp at lithe% bzr shelve
--- Makefile	2008-12-06 20:51:56 +0000
+++ Makefile	2008-12-09 23:27:39 +0000
@@ -1,2 +1,5 @@
-check:
+all:
+	python setup.py build
+
+check: all
 	python -c 'import doctest; doctest.testfile("README")'
Shelve? [yNfq]

  after shelving the changes, commit them, then use bzr unshelve.
This creates a separate clean revision on this branch.

  To extract just that change onto a separate branch, you could do eg

  bzr branch -r -1 ../makefile-build

-1 meaning the last committed revision.

(2) another tool here is the "merge --uncommitted" option, which
brings only the uncommitted changes across into a new working tree.

  cd ../doc
  bzr merge --uncommitted ../general-development/README

(3) there's also the 'bzr loom' plugin, which supports development of
focussed patches with dependencies between them on different threads,
see http://www.flamingspork.com/blog/2008/02/22/bzr-loom-a-bzr-plugin-with-quilt-like-functionality/
and https://lists.ubuntu.com/archives/bazaar-announce/2008-February/000133.html

> PEP101

I don't know enough about this; can you work through it with us, Barry?

> Bazaar also has the benefit of being written in pure Python, making a Python VM the bare minimum requirement to work.

This is correct, but it's worth noting that bzr is much faster if you
build the extension modules.

> Hosting

[Kiko named a code release date for Launchpad at UDS; I think it was
July 2009.  I can't find a web cite for this yet though.  I will poke
him to post about it.  Obviously having a promise is not as good as
already having the code, but it's something.]

> Special Features

Let's come up with some more here:

bzr has a stable Python scripting interface, with a distinction
between public and private interfaces and a deprecation window for
APIs that are changing.  Some plugins are listed in
<https://edge.launchpad.net/bazaar> and
<http://bazaar-vcs.org/Documentation>

-- 
Martin <http://launchpad.net/~mbp/>