What we did at UBZ

[Aaron Bentley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I had a great time at Ubuntu Below Zero.  It's a Canonical conference,
covering both the Ubuntu distro, and Launchpad, the tools Canonical is
developing to support Ubuntu.  Bazaar-NG is now being used by Launchpad
developers to create tools to create Ubuntu, which makes us a meta-meta
project.

The use of bzr in Launchpad is a new thing, and it has only happened
because of a lot of dedicated work by Robert Collins.  Christian Reis
(Kiko) bet him that Launchpad wouldn't transition to bzr before UBZ, and
Robert won that bet.  I saw Kiko get a pie (well, cake) in the face with
my very own eyes.

http://www.flickr.com/photos/mbp_/61725150/

It was nice to see Martin Pool, Robert Collins, James Blackwell, David
Allouche, and all the other Canonical folks again.  And it was great to
meet John Meinel (which, it turns out, is pronounced my-NEL).  And they
all got to see my newly-red hair:
http://www.flickr.com/photos/mbp_/60935721/in/set-1322173/

It was great to hear from so many people that bzr was working really
well for them.  At the same time, we gathered a lot of feedback about
what people needed, and that has been put on the
http://bazaar.canonical.com/BzrAdoptionBlockers page.  There's a lot of
cool high-tech stuff in this project, so it can be easy to forget about
all the low-hanging fruit.

We were supposed to be developing specs, and we didn't entirely succeed
on that front.  But we did have a lot of fruitful discussions, and the
way forward is now a lot clearer

Ghost Revisions
===============
Despite his misgivings, we've convinced Martin that revision ghosts
should be a supported feature, and that any problems with them should be
treated as bugs.

Centralized Development
=======================
We managed to clarify our definitions here.  The components of
centralized development that we identified were
~ - Lock-step development
~ - Centralized storage

Lock-step development
=====================
http://bazaar.canonical.com/LockStepDevelopment

For some workflows, the CVS approach of update-before-commit is the
best.  For example, you might have an organization where everyone works
on their own branches, then merges their work into the mainline when
it's ready.  Or maybe you have a system where everyone works directly on
the mainline (ick!).  Or maybe you're a lone developer who works on the
same branch from more than one location.

For each of these, bound branches are a great solution.  They make it
impossible to be accidentally out of date, because each commit is a
push, and you can't commit if the local branch is out of date.  There's
still some disagreement on the UI for working offline, but we will make
sure it is straightforward.

Centralized storage
===================
http://bazaar.canonical.com/BzrArchives

We will introduce 'archives'.  Much like the archives in Arch, they will
be structures that contain both branches and revisions.  They will not
have working trees.  You will be able to name your branches pretty much
anything, within the archive. (Except, maybe ./+storage)  Branch naming
will be explicit, not implicit as in the centralized storage design I
proposed.

Differences from Arch:
- - Branches can safely be removed from archives
- - There are no naming rules

We're now referring to our current branches as 'standalone branches'.

To complement archives, we will introduce 'checkouts'. Much like CVS
checkouts, these will be working directories that contain no branch
data.  They will have a last-revision and a reference to a branch (which
will often be an archive branch).

Bound Archive Branches
======================
For many of us, bound branches and archives will combine nicely.
I'll have a local archive both at home and at work.  All the branches in
both archives will be bound to my remote archive, so that my public
branches are always up-to-date.  I'll do all my work in checkouts, so
branching will be extremely cheap, and will happen both locally and
remotely at the same time.  (Somehow.  The UI isn't quite sorted)


Nested tree support
===================
http://bazaar.canonical.com/BzrNestedTreeSupport
There are several reasons for good nested tree support
~ - Several projects may use the same library, so it should have a
separate identity.  But it should be easy to ensure that when you get a
project, you get the right version of the library.

- - Projects may sometimes combine, and we should support that well

We plan two types of nested tree support: by-value and by-reference.
By-value means that the two projects become one bzr tree.

By-reference means that the outer project will be able to 'add' the
library tree, and committing will record the revision of the library
tree.  So when you pull, the revision of the library may change, and if
it does, you'll automatically get the correct library revision, too.

Network performance
===================
http://bazaar.canonical.com/IntegratingTwisted
http://bazaar.canonical.com/SmartServer
We've decided that bzr will not become a Twisted program at this time.
We'll create a smart server and pursue other options for increasing speed.

Cherry-pick metadata
====================
http://bazaar.canonical.com/BzrCherrypickMetadata
We've decided to defer this support until later.


Pull convergence
================
We discussed the possibility of removing pull convergence from the
model, but we haven't made any final decisions.  The idea of pull
convergence was that after a branch had merged you, you could pull that
branch, and get their revision in your branch history.  This eliminates
ping-pong merges, where each branch merges the other and commits, ad
infinitum.

But having two points-of-view about branch history complicates things.
Removing this behavior would mean
- - the revno of a given revision would be clearly defined
- - tags could be implemented as pointers to revisions, with no need for
them to include revision history.

Storage Layer
=============
I've already done most of the work of separating out a storage layer
from the Branch object.  This is useful for archive branch support, but
also just for clarity-- several developers have thought that the only
revisions stored in a branch were the ones in its ancestry.

There's probably more I've forgotten, but this should be a good starting
point, at least.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDd1wU0F+nu1YWqI0RAtFYAJkBF59dwEsKwyJpjRfLubxx0f+BVgCfSEMI
FWXOy7egRDEfix7wFFmpLjo=
=S8hR
-----END PGP SIGNATURE-----