Bazaar

One of the transports available in bzr is sftp. This is implemented using the Paramiko SSH and SFTP library. Unfortunately there are a few issues I experienced with the code: Since it is an independent implementation of SSH, none of my OpenSSH settings in ~/.ssh/config were recognised. The particular options I rely on include: User: when the remote username doesn't match my local one. One less thing to remember when connecting to a remote machine. IdentityFile: use different keys to access different machines. ProxyCommand: access work machines that are behind the firewall. Paramiko does not currently support SSH compression. This is a real pain for larger trees. The easiest way to fix all these problems would be to use OpenSSH directly, so wrote a small plugin to do so. I decided to follow the model used to do this in gnome-vfs and Bazaar 1.x: communicate with an ssh subprocess via pipes and implement the SFTP protocol internally. Since SFTP is layered fairly cleanly on top of SSH, and the paramiko code was also quite modular, it was possible to use the paramiko SFTP implementation with openssh. The result is a small plugin that monkey-patches the existing SFTP transport: http://people.ubuntu.com/~jamesh/bzr-openssh-plugin/ Just copy openssh-sftp.py into the ~/.bazaar/plugins directory, and use bzr as normal. The compression seems to make a noticable difference to performance, but it should be possible to improve things further with a pipelined SFTP client implementation. Of course, the biggest performance optimisation will probably come from the smart server, when that is implemented.

When a project grows to a certain size, it will probably need a way to share code between multiple software packages they release. In the context of Gnome, one example is the sharing of the libbackground code between Nautilus and gnome-control-center. The simplest way to do this is to just copy over the files in question and manually synchronise them. This is a pain to do, and can lead to problems if changes are made to both copies, so you'd want to avoid it if possible. So most version control systems provide some way to share code in this way. As with the previous articles, I'll focus on Bazaar, CVS and Subversion Unlike the common operations each system implements this feature in a different way, so I'll go over each one in turn and then compare them. CVS When you run the "cvs checkout module" command, CVS will look in the CVSROOT/modules file for the repository. For example, the file might contain the following: module foobar This would tell CVS to check out the foobar directory from the repository into a directory named module when the user asks for module. If no entry is found for a particular name, the directory by that name is checked out from the repository. To compose multiple modules into a single working copy, the ampersand syntax can be used: module foo &bar &baz bar othermodule/bar With this modules file, "cvs checkout module" would give the following working copy: Working Copy Repository module foo module/bar othermodule/bar module/baz baz Operations like tag, commit, update, etc will descend into included modules, so for the most part a user can treat the resulting working copy as a single tree. If a particular branch tag exists on all the included modules, you can even check out a branch of the combined working copy. There are some problems with the support though: While "cvs update" will update the working copy, it won't take into account any changes in CVSROOT/modules. If you've only got write access to part of the repository, and can't write to CVSROOT/modules, then you can't change configurations. While CVS lets you check out old versions of code, you still use the latest version of CVSROOT/modules. This can make it difficult to check out historical versions of the tree. Since "cvs tag" descends into included modules, you can end up with many branch tags on some modules. For instance, the gnome-common/macros directory in Gnome CVS has 282 branch tags, which makes it almost impossible to feed fixes to all those branches. Subversion Rather than a single repository-wide file describing the module configuration for checkouts, Subversion makes use of the svn:externals property on directories. Any directory can have such a property attached. Each line in the property is of the form: subdir [-rrevnum] absolute-uri-of-tree-to-include This will check out each the given tree at the given sub dir when ever "svn checkout" or "svn update" are used. However unlike CVS, "svn commit" will not descend into the included modules. Some…