–create-prefix not needed with bazaar.launchpad.net

When outlining the use of team branches on Launchpad previously, I used the --create-prefix option when pushing the branch to sftp://bazaar.launchpad.net. This was to make sure the initial push would succeed, even if the /~username/product directory the branch would be created in didn't exist. To simplify things for users, we made a change to the SFTP server in the latest release, so that --create-prefix is no longer necessary. This does not affect the allowed branch directories though: the structure is used to associate the branches with products, and decide who can write to the branches. Another change included in the rollout is the ability to rename branches and reassign them to different owners through the web interface. So for instance, you can give ownership of a personal branch to a team your project grows to multiple developers. This should be used sparingly, since it will change the published branch URLs which can confuse people using your branch.

Gnome-gpg 0.5.0 Released

Over the weekend, I released gnome-gpg 0.5.0. The main features in this release is support for running without gnome-keyring-daemon (of course, you can't save the passphrase in this mode), and to use the same keyring item name for the passphrase as Seahorse. The release can be downloaded here: http://download.gnome.org/sources/gnome-gpg/0.5/ I also switched over from Arch to Bazaar. The conversion was fairly painless using bzr baz-import-branch, and means that I have both my revisions and Colins revisions in a single tree. The branch can be pulled from: bzr branch http://www.gnome.org/~jamesh/bzr/gnome-gpg/devel gnome-gpg All of the converted revisions authored by me have been signed with my PGP key. As signatures can't get moved over in the conversion process, none of Colin's revisions are signed. Note that the signatures in Bazaar are for particular tree states rather than changes between two tree states, so it doesn't affect the trust of the current revisions. While I was at it, I also converted the other branches I had in my www.gnome.org Arch archive over to bzr. The only other branch that people might find useful is the http-resource code, which I've updated to compile with the latest libsoup.

Shared Branches using Bazaar and Launchpad

Earlier, David Allouche described how to host Bazaar branches on Launchpad. At the end, he alluded to the ability to create branches that can be committed to by anyone on a team. I'll describe how this works here. Launchpad Teams Launchpad allows people to organise themseleves into teams. Most of the things people can do in Launchpad can also be done by teams, including owning branches. You can create a new team at the following page: https://launchpad.net/people/+newteam There are three different membership policies you can choose from: Open: anyone can join. Choosing this sort of team effectively gives everyone write access to branches owned by the team. Moderated: new memberships must be approved by one of the administrators (this is the default policy). This makes it easy for people to request commit access to the branch while still requiring approval from a team administrator.. Restricted: new members can only be added by the team administrators. This is appropriate if new members shouldn't be able to propose themselves normally. Once the team has been created, members of the team can create the branches. Uploading a Team Owned Branch Now that you are a member of a team, you can upload branches to that team's directory on bazaar.launchpad.net. This is done in the same way as uploading personal branches described in David's article: cd branchdir bzr push --create-prefix sftp://bazaar.launchpad.net/~teamname/product/branchname When the command completes, the team owned branch will have been created. Now you can treat this branch like a personal branch, but once someone else pushes a commit to the branch, "bzr push" will tell you that the branch has diverged, and not let you push your changes until you merge them to your branch. An alternative model is to use checkouts, which provide a workflow closer to CVS and Subversion without losing Bazaar's ability to work while disconnected. Bazaar Checkouts A Bazaar checkout is a local working copy bound to a remote branch such that changes are committed to the remote location. The remote branch data is also cached locally to speed up local operations and allow you to work while disconnected from the network. A checkout of the previously created team branch can be created with the following command: bzr checkout sftp://bazaar.launchpad.net/~teamname/product/branchname team-branch cd team-branch Alternatively if you still have the local branch used to create the team branch, it can be converted to a checkout with the "bzr bind" command: cd branchdir bzr bind sftp://bazaar.launchpad.net/~teamname/product/branchname You can then make commits to the checkout as you would with any other branch, provided the checkout is up to date with the remote branch. If another team member has committed to the branch in the mean time though, you will be prompted to update your checkout to the head of the latest version of the remote branch. If this happens, the checkout can be updated by issuing the "bzr update" command. You can then retry the commit, after fixing any conflicts that are reported. Disconnected Operation with Checkouts If you are disconnected…

Hosting bzr branches on Launchpad

Have you wanted to play around with bzr but had nowhere to share your branches? You can now publish them through Launchpad. David Allouche provides the details. In short, you can upload branches to sftp://bazaar.launchpad.net/, and they will be published on http://bazaar.launchpad.net/.

JHBuild Improvements

I've been doing most JHBuild development in my bzr branch recently. If you have bzr 0.8rc1 installed, you can grab it here: bzr branch http://www.gnome.org/~jamesh/bzr/jhbuild/jhbuild.dev I've been keeping a regular CVS import going at http://www.gnome.org/~jamesh/bzr/jhbuild/jhbuild.cvs using Tailor, so changes people make to module sets in CVS make there way into the bzr branch. I've used a small hack so that merges back into CVS get recorded correctly in the jhbuild.cvs branch: Apply the diff between jhbuild.cvs and jhbuild.dev to my CVS checkout and commit. Modify tailor to pause before committing the to jhbuild.cvs. While tailor is paused, run bzr revert followed by a merge of the same changes from jhbuild.dev. Let tailor complete the commit. It's a bit of a hack, but it allows me to do repeated merges from the CVS import to my development branch (and back again). It also means that any file moves I do in my bzr branch are reflected in the CVS import when merged. So now when filing bug reports on jhbuild, you can submit fixes in the form of bzr branches as well as patches. So, on to the improvements: Generic Version Control Interface Previously, to add support for a new version control system the following additions were needed: Some code to invoke the version control utility to make checkouts and update working trees. Code to implement the build state machine for modules using the version control system (these classes would generally derive from AutogenModule which implemented most of the build logic). Code to create instances of the above module type when parsing .modules files. This was quite a bit of work, and in the end would only help if the code in question was set up to build the same way as most Gnome modules (i.e. with a autogen.sh script and autotools). If you wanted to build a module using Python distutils out of Subversion, a new module type would be needed. If you wanted to build a distutils module from a tarball, that would be another module type again. With the new system, the different version control support modules provide a common interface. This means that a single module type is capable of implementing the build state machine for any version control system. Similarly, it should now be possible to implement distutils module support such that it will work with any supported version control system. This work is not yet finished though. A bit more work needs to be done to parse version control system agnostic module definitions from .modules files. When this is done, a fair bit of the current syntax can be deprecated and eventually removed. When this is done, adding support for a new version control system shouldn't take more than 100-200 lines. Module Type Simplifications As well as reducing the number of module types that need to be maintained in JHBuild, I've been working on simplifying the code in these module types. Previously, each stage of a module build was represented by a method call on…