Ubuntu Documentation / Bzr

[Matthew East]

Hi all,

Steve contacted me about this subject and Matthew has emailed me about
it too in the past so I thought a group discussion would be helpful.
I'm writing to the mailing list too so that everyone can contribute
their ideas.

I'd like to hear what people think about this issue. There seems to be
quite a substantial push behind bzr, and while from my own point of
view I find it a little bit hard to get too excited one way or another
about what version control system we are using, I can see that it's
worth at least discussing.

We've been using bzr a bit recently for creating a branch of
customised Gnome documentation for use in Ubuntu [1], so I've
experienced how it works a bit, although I'm still only a beginner.
Please correct my analysis if it is wrong.

[1] https://code.launchpad.net/~ubuntu-doc/gnome-user-docs/ubuntu-changes

The Documentation Team is made up of many volunteers each of who gives
as much time as they can to the project, depending on their
availability. For this reason we use a centralised model of
development where each person commits directly to a repository. While
I'm open to discussion, I suspect that this is something that we will
wish to continue.

As I see them, the advantages that bzr would give us in such a
workflow would be:

 * Launchpad integration - easier control of the group of persons who
can commit to the repository.
 * For contributors, the ability to submit bundles rather than patches
so that their version control information is preserved.

The disadvantages over our current workflow are:

 * Speed seems poor compared to svn: because the whole revision
history is downloaded when branching, there is more material to
download.
 * Bzr's feedback during upload/download is pretty bad - for example
when checking out a branch of our repository the status indicator
generally starts at 30%, takes an hour to get to 50%, then jumps
quickly to 100%.

To be honest, (although I'm slightly concerned about the speed issue)
both the advantages and the disadvantages at the moment seem
relatively insignificant. It may be that they don't warrant changing
version control systems at this stage, which would require a certain
amount of effort, rewriting of our documentation, and generally as
contributors getting used to a new system.

However, I think it's likely that in the future there will be some
more substantial advantages. For example, I'm told that there are
plans for Launchpad to support shared repositories, which will permit
revision history to be stored on the serverside only and improve
download speeds. Maybe there will be other improvements too.

Thoughts?

-- 
Matthew East
http://www.mdke.org
gnupg pub 1024D/0E6B06FF