Posts tagged 'bzr_svn'

Samba 4 and OpenChange daily Ubuntu packages

Daily builds

As of a month ago there are Ubuntu archives with fresh packages of Samba 4 and OpenChange, built on a daily basis day from the latest upstream revision.

This means that it is now possible to run a version of Samba 4 that is less than 24 hours old, without having to know how to extract source code from the version control system that upstream is using, without having to know how to build and install an application from source, but perhaps most importantly: without having to go through the tedious process of manually updating the source code and rebuilding.

OpenChange is tightly coupled to Samba 4, so installing a new version of OpenChange usually involves installing a new version of Samba 4 as well. To make matters more confusing, the two projects use different version control systems (Samba 4 is in Git, while OpenChange is in Subversion) and different build systems (Samba 4 uses waf, OpenChange uses autoconf and make).

I have been involved in Samba 4 and OpenChange as an upstream developer and more recently also as a packager for both Debian and Ubuntu.

As an upstream developer for both these projects it is important for me that users can easily run the development versions. It makes it possible for interested users to confirm the fixes for issues they have reported and to test new features. The more users run the development version, the more confident I can be as a developer that doing a release will not cause any unexpected surprises.

As a packager it is useful to know when there are upstream changes that are going to break my package with the next release.


The daily builds work using so-called recipes which describe how to build a Debian source package from a set of Bazaar branches. For example, the Samba 4 recipe looks like this:

# bzr-builder format 0.2 deb-version 4.0.0~alpha14~bzr{revno}~ppa{revno:packaging}+{revno:debian}
merge debian lp:~samba-team/samba/unstable
merge packaging lp:~samba-team/samba/4.0-ppa-maverick

This dictates that a source package should be built by taking the upstream Samba branch and merging the Debian packaging and some recipe-specific tweaking. The last bit on the first line indicates the version string to be used when generating a changelog entry for the daily build.

Every night Launchpad (through bzr-builder) merges these branches and attempts to build the resulting source package, e-mailing me in case of build problems. Generally I fix issues that come up by committing directly to upstream VCS or to the Debian packaging branch. There is no overhead in maintaining the daily build after I’ve set it up.

For more information on creating source package recipes, see getting started.


The entire toolchain that does the daily package builds for Ubuntu is Free Software, and I have contributed to various bits of that toolchain over the years. It’s exciting to see everything come together.


Launchpad consists of multiple pillars - one of those pillars is Soyuz, which I hack on as part of my day job at Canonical. Soyuz is responsible for the archive management and package building. Debian source packages (a combination of upstream source code and packaging metadata) get uploaded by users and then built for various architectures on our buildfarm and published to the Ubuntu archive or to users personal package archives.


Another pillar of Launchpad is Launchpad-code, which is responsible for the hosting and management of version control branches. Launchpad users can either host their branches on Launchpad directly or mirror branches (either native Bazaar branches or branches in a foreign format such as Subversion, Git or Mercurial). The mirrorring of native and foreign branches happens using standard Bazaar API’s. In the case of Samba and OpenChange we import the branches of the upstream projects (Samba is in Git, OpenChange is in Subversion) and the packaging for both projects is in Bazaar.

Launchad-code calls out to Bazaar to do the actual mirrorring. Over the last few years I have done a lot of work to improve Bazaars support for foreign branches, in particular on supporting Subversion, Git and Mercurial. As the code mirrorring in Launchpad is one of the biggest users of bzr-svn and bzr-git it has helped find some of the more obscure bugs in those plugins over the last few years, to the point where there are only a handful of issues with Git imports and Subversion imports left.

bzr-git and dulwich

bzr-git provides transparent access to Git repositories from within Bazaar and is built on top of Dulwich. Dulwich is a Python library that provides access to the Git file formats and protocols that is completely independent of Bazaar. James Westby originally started it and I adopted it for bzr-git and further extended it. There are now several other projects that use it as well, including hg-git, and rabbitvcs. Apart from James and myself, almost two dozen other people have contributed it so far.

bzr-svn and subvertpy

bzr-svn provides transparant access to Subversion repositories in Bazaar. When I grew frustrated with the existing Subversion Python bindings for various reasons, I decided to create independent Python bindings for Subversion from scratch. These bindings have since been split out into a separate project - subvertpy - and other projects have since also started using them, e.g. hgsubversion and basie.

Using the daily builds

To use the Samba 4 and OpenChange daily builds (Ubuntu Maverick only for now), run:

$ apt-add-repository ppa:samba-team/ppa
$ apt-add-repository ppa:openchange/daily-builds

Currently Playing: Karnivool - Themata


bzr-builddeb FTW

% bzr branch deb:line6-usb-source debian
Retrieving Vcs locating from line6-usb-source Debian version 0.7.4-1
Branched 354 revision(s).
% bzr merge-upstream
All changes applied successfully.
Using version string 0.7.4+svn511 for upstream branch.
The new upstream version has been imported. You should now update the changelog (try dch -v 0.7.4+svn511-1 "New upstream snapshot."), resolve any conflicts, and then commit.
% dch -v 0.7.4+svn511-1 "New upstream snapshot.
% bzr builddeb
Building using working tree
Preparing the build area: ../build-area
Purging the build dir: ../build-area/line6-usb-0.7.4+svn511
Placing result in /home/jelmer/bzr/line6-usb/result
% ls ../result
line6-usb_0.7.4+svn511-1_amd64.changes  line6-usb_0.7.4+svn511-1.dsc
line6-usb_0.7.4+svn511-1.diff.gz        line6-usb_0.7.4+svn511.orig.tar.gz

Currently Playing: Phideaux - Microdeath Softstar


bzr-svn push without file properties

Ever since bzr-svn started supporting “true push”, people have been complaining about the extra file properties it sets.

The key thing about “true” push is that it preserves the exact revisions that were present in Subversion. This lets bzr behave on Subversion branches transparently using the same UI you also use for “native” Bazaar branches.

In other words, if I push to a Subversion branch from my machine, then that branch in Subversion contains enough information for somebody else to reconstruct the exact bzr branch I had.

Since some Bazaar metadata can not be represented in Subversion, it is stored in Bazaar-specific Subversion properties. Unfortunately, these file properties show up in email commit notifications and trac and so they tend to annoy people.

There are two ways around this:

Revision properties

Bazaar-specific metadata can be stored in in custom Subversion revision properties (these don’t show up in commit notifications). Unfortunately, this requires Subversion 1.5 or newer to run on the server.

I hope to start setting revision properties instead of file properties when possible as of the next bzr-svn release.

less strict push

It’s also possible to throw away any data that can not be represented in Subversion. Since this means that the remote branch won’t end up an exact same copy of the local revisions, this isn’t true push. The two branches will have diverged (no matter how slightly) after such a push so it is necessary to rebase on the remote branch after pushing.

This is similar to the way git-svn pushes data into Subversion - it calls it “dcommit”.

Since this uses rebase it has the usual disadvantages of rebases, which I won’t get into right now.

As of a couple of days ago, bzr-svn now also supports this mode of pushing using the “dpush” command, by popular demand.

Currently Playing: Brandi Carlile - The Story


bzr-svn: now with its own Subversion Python bindings

bzr-svn has always been using the standard Python bindings that were provided with Subversion itself. Unfortunately, I had to fix some issues in these bindings since they were incomplete or broken and thus bzr-svn has always depended on a development snapshot of Subversion.

As of today, bzr-svn is using its own Python bindings for Subversion.

There were several reasons for switching to our own bindings:

  • There are no requirements for backwards compatibility within bzr-svn. This means the API can be made sane without worrying about the mess it was in the past and users who still rely on that.
  • Deployment. It took 2 years for my fixes to the Subversion Python bindings to be part of a release. It’ll be even longer before Subversion 1.5 makes it into most available distributions. That makes it very hard to just download and install bzr-svn.
  • They’re in plain C, not SWIG. SWIG has a big advantage for the Subversion folks since it can generate python, ruby, java or tcl bindings all at once without a lot of overhead per language. However, it has issues as well that make it a bad choice for bzr-svn.
    • It generates inefficient code - it generates proxy classes that add more layers in the stack
    • Bindings tend to be very much like the C API rather than “Pythonic”. To make them more Pythonic, you need tons of typemaps. For example, the Python bindings in bzr-svn provide an iterator when browsing the revision history rather than a callback as C and the SWIG bindings do.
    • Hard to write - personally at least, I write bindings in C faster than in SWIG
    • Adds an extra dependency to the build process. Several people had trouble building Subversion on their Mac machines because they didn’t have the right version of SWIG available.

Since all of the patches that bzr-svn depended on previously were in the Python bindings for Subversion, it is now possible to use bzr-svn with any version of Subversion newer than 1.4.0. Of course, you do need to have the development headers installed as well.

Currently Playing: Kathleen Edwards - Independent Thief


Bazaar in the GNOME world

I was happy to see that John Carr has set up a Bazaar Mirror of all projects in GNOME Subversion, all created using bzr-svn. There’s also a quick introduction to using Bazaar for GNOME developers on the GNOME Wiki.

Wouter, long time Bazaar user and GNOME dude, recently blogged about pushing Bazaar branches into GNOME Subversion, working around the restrictions imposed by the pre-commit hooks in GNOME Subversion.

The problems John ran into with memory usage in the Python Subversion bindings encouraged me to continue the work on bzr-svn’s own Python bindings, thus avoiding any dependency on unreleased versions of Subversion and several other issues.


Using bzr-builddeb as a svn-buildpackage replacement

This slightly evil hack to bzr-svn allows using bzr-builddeb as a drop-in replacement for svn-buildpackage, making it recognize the “mergeWithUpstream” property svn-buildpackage uses.

Currently Playing: Jeff Healey - Mess O’ Blues



The next major release of bzr-svn, 0.4, has now been released. The main change in this release is that the behaviour of push is now intuitive. The big hack that allowed push to somewhat work in the previous release has been replaced by proper push which behaves the same way as it would against a Bazaar branch.

It’s now also possible to branch from non-standard branch locations such as /foo in a repository and not necessarily standard locations like /trunk or /trunk/foo. See the release announcement for a list of other changes.

It’s interesting to see what other people are saying about bzr-svn on their blogs:

Note that bzr-svn 0.4 has been tested on Windows and that branching schemes are now more flexible.


Using a pqm with Subversion

One of the things that I’ve always missed in DVCS is the ability to refuse commits in a branch that’s shared by multiple people based on a test suite run. Sure, it’s possible to have a pre-commit hook - but that would mean that you’d have to wait for the full test suite to run until the commit finishes. With the time it takes to run the Samba testsuite, this is not really an option.

One of the things that would work is to have everybody work in a separate branch and then have some sort of tool that merges those revisions from everybody’s personal branches that worked ok. However, to my knowledge, there is no such tool for Subversion.

Bazaar uses a tool called PQM (Patch Queue Manager). PQM usually controls the main branch (for example for Bazaar, it controls, and waits for GPG-signed requests to merge a specific revision into that main branch. Before accepting such a revision, it will try to run the testsuite to make sure it passes. This guarantees that the main branch never contains broken code (as far as can be indicated by the testsuite).

Now that bzr-svn supports true push, it is possible to actually use a PQM with a Subversion branch. I’ve tried it on a smaller branch last week, and am now looking into using this for my Samba work.



I’m currently doing a bit of sightseeing in London, after attending the Bazaar sprint at the Canonical office. It was a good sprint, and quite different from the previous ones - in that there was only a limited amount of actual coding involved. The view from the Canonical office is magnificent, so we were even able to do some sightseeing while working…

Bazaars’ focus has previously mainly been on correctness and features. The first has always been one of our strengths, and we’re in pretty good shape regarding the second. Performance has been one of the main complaints from users about Bazaar and so we have recently tried to improve in that area.

Since 0.12, we have already tried to optimise some of the common code paths and some people have been working on a high performance smart server (to speed up remote operations).

During the first two-and-a-half days of the sprint, we analysed 20 of the most common use cases with Bazaar and determined what complexity they should ideally require to be able to work. After this analysis, we looked at ways to change our data structures to reach these goals.

I have mainly been a spectator during the latter parts of these discussion, but they were interesting to follow.

One of the things I worked on was support for true push in bzr-svn. This was one of the bugs that has bitten a lot of users of bzr-svn. The upcoming bzr-svn 0.4 now supports true push as well as commits in heavyweight checkouts. I hope to release 0.4 after adding nested tree and ignores support so that I don’t have to change the internal mapping mechanisms again.

And now, it is time for some more sightseeing. After that I hope to get back to the reason I’m doing all of this in the first place: Samba!


Bazaar and Subversion nested tree support

As of 0.15, Bazaar will have initial support for nested trees. Nested trees basically allow you to add a ‘magic’ directory to a Bazaar branch that in itself is another Bazaar branch. A very good use case of this is if you have a project for which you need to include some library (e.g. popt). Nested trees allow you to add a reference to the upstream popt branch, avoiding the need to synchronize every time upstream fixes a bug.

Subversion has similar functionality, although the term used there is ‘externals’. Externals are quite easy to use - using them only requires setting the svn:externals property.

I’ve done some early work on supporting externals in bzr-svn and mapping them to nested trees. At the moment, bzr-svn is able to track nested trees that are being added. Removes and changes to existing nested tree locations are still on my todo list, but will definitely be supported in bzr-svn 0.4.0.