Uncategorised

Bryan’s Bazaar Tutorial

Bryan: there are a number of steps you can skip in your little tutorial: You don't need to set my-default-archive. If you often work with multiple archives, you can treat working copies for all archives pretty much the same. If you are currently inside a working copy, any branch names you use will be relative to your current one, so you can still use short branch names in almost all cases (this is similar to the reason I don't set $CVSROOT when working with CVS). If you have a directory which contains only the files you want to import into your Bazaar archive, the following command will add them all, and convert the directory into a Bazaar working copy: cd background-channels baz import -a bclark@redhat.com--gnomearchive/background-channels--dev--0.1 No need for init-tree, add or commit. Running archive-mirror in your working copy will mirror that archive, so doesn't need my-default-archive set. Other people probably don't want to set your archive as their default. Also, they can ommit the register-archive call entirely: baz get http://gnome.org/~clarkbw/arch/background-channels--dev--0.1 This checks out the branch, and registers the archive as a side effect. If you want to find out what is inside an archive, the following command is quite convenient: baz abrowse http://gnome.org/~clarkbw/arch Some things you might want to do: If you have a PGP key, create a signed archive. This will cryptographically sign all revisions. When people checkout your branches, the signatures get checked automatically (this is useful if the server hosting your mirror gets broken into and you need to verify that nothing has been tampered with). If you have already created the archive, you can turn on signing with baz change-archive (remember to update the mirror archive too). If you turn on signing, consider using a PGP agent like gnome-gpg. You can configure it in ~/.arch-params/archives/defaults. It is customary to name the archive directory the same as the archive name. This has the benefit that the branch name matches the last portion of the URL. If you haven't set up a revision library, you should do so: mkdir ~/.arch-revlib baz my-revision-library ~/.arch-revlib baz library-config --greedy --sparse ~/.arch-revlib

pkg-config vs. Cross Compile and Multi-arch

One of the areas where pkg-config can cause some problems is when trying to cross compile some code, or when working with multi-arch systems (such as bi-arch AMD64 Linux distros). While it is possible to use pkg-config in such systems by manipulating $PKG_CONFIG_PATH and/or $PKG_CONFIG_LIBDIR, users can't just follow the instructions given for the single-arch case. After some discussion with Wolfgang Wieser, we came up with a proposal for better supporting cross-compile and multi-arch uses. The main changes would be: Add a new --host option pkg-config. This would allow pkg-config to use different default search paths based on the host type, and search for .pc files in host type specific subdirs on the search path. If an unknown host type is given, then no default search path is disabled altogether. The autoconf macro would pass this argument whenever it detected that pkg-config supported it. For the common case, this should allow most packages to be built for the non default architecture on a bi-arch system, or cross compiled, by just passing --host=foo to configure and (you might still need to set $CC or $CFLAGS, depending on the compiler setup). For packages that install .pc files, they should continue to work. However it will be worth updating them to install their .pc file into a host type specific sub directory (the autoconf macros will make this easy to do). If this code is likely to affect you, send comments to the pkg-config mailing list (or leave comments here).

Merging In Bazaar

This posting follows on from my previous postings about Bazaar, but is a bit more advanced. In most cases you don't need to worry about this, since the tools should just work. However if problems occur (or if you're just curious about how things work), it can be useful to know a bit about what's going on inside. Changesets vs. Tree Snapshots A lot of the tutorials for Arch list "changeset orientation" as one of its benefits over other systems such as Subversion, which were said to be based on "tree snapshots". At first this puzzled me, since from my mathematical background the relationship between these two concepts seemed the same as the relationship between integrals and derivatives: A changeset is just the difference between two tree snapshots. The state of a tree at a particular point in just the result of taking the initial tree state (which might be an empty tree), and applying all changesets on the line of development made before that point. The distinction isn't clear cut in the existing tools either -- Subversion uses changesets to store the data in the repository while providing a "tree snapshot" style view, and Bazaar generates tree snapshots in its revision library to increase performance of some operations. So the distinction people talk about isn't a simple matter of the repository storage format. Instead the difference is in the metadata stored along with the changes that describes the ancestry of the code. Changesets and Branching In the simple case of a single branch, you end up with a simple series of changesets. The tree for each revision is constructed by taking the last revision's tree and applying the relevant changeset. Alternatively, you can say that the tree for patch-3 contains the changesets base-0, patch-1, patch-2 and patch-3. Branching fits into this model pretty well. As with other systems, a particular revision can have multiple children. In the diagram below, the trees for both patch-2 from the original branch and patch-1 from the new branch "contain" base-0 and patch-1 from the original branch. Any apparent asymmetry is just in the naming and storage locations -- both revisions are branches are just patches against the same parent revision. So far, there's no rocket science. Nothing that Subversion doesn't represent. Pretty much every version control system under the sun tracks this kind of linear revision ancestry (as can be seen using svn log or similar). The differences really only become apparent when merges are taken into consideration. Merges Just as a particular revision can have multiple child revisions (a.k.a. branching), a tree can have multiple parent revisions when merges occur. When you merge two revisions, the result should contain all the changes that exist in the parent revisions. In the above diagram, we want to merge the changes made on the second branch back into the original one. The usual way to merge changes goes something like this: Identify the most recent common ancestor of the two revisions. Take the difference between…

First Thoughts on NewsBruiser

I've moved my diary over to blogs.gnome.org, which offers a few extra features over advogato (the main ones I'm interested in are more control over the layout, and the ability to embed images). Overall it seems pretty good, although I have a few gripes: The login cookie gets set for the path /nb.cgi/ only, so when I go to the front page of my diary, which is not under that path due to some mod_rewrite magic, it never thinks I'm logged in. My login cookie gets sent to all pages under /nb.cgi/, including other hosted blogs. Given that I can put arbitrary HTML in the templates for my blog, it would be possible to capture the passwords of other NewsBruiser users on the system without much trouble (it's a good thing we all trust each other). This one is a bit difficult to fix because of the URI structure for newsbruiser pages, which look like "/nb.cgi/verb/username/...". If they were structured with the username first, it would be trivial to set up the cookie so it only gets sent when viewing one particular blog. Overall though, it seems quite nice.

Bazaar (continued)

I got a few responses to the comparison between CVS, Subversion and Bazaar command line interfaces I posted earlier from Elijah, Mikael and David. As I stated in that post, I was looking at areas where the three systems could be compared. Of course, most people would choose Arch because of the things it can do with it that Subversion and CVS can't. Below I'll discuss two of those things: disconnected development and distributed development. I'll follow on from the examples in the previous post. Disconnected Development Disconnected development allows you to continue working on some code while not having access to the main repository. I hinted at how to do this in the previous post, but left out most of the details. The basic steps are: Create an archive on your machine Branch the module you want to work on into your local archive. Perform your development as normal When you connect again, switch back to the mainline, merge your local branch and commit the changes. To create the local archive, you follow the same procedure as for creating the original archive. Something like this: mkdir ~/archives baz make-archive --signed joe@example.com ~/archives/joe@example.com This creates an archive named joe@example.com (archive names are required to be an email address, optionally followed by some extra info) stored in the user's home directory. Now we can create a branch in the local archive. From a working copy of the mainline branch, run the following command: baz branch joe@example.com/modulename--devel--0 It was necessary to specify an archive name in this call to baz branch, because the branch was being created in a different archive to the one the working copy was pointing at. This leaves the working copy pointing at the new branch, so you can start working on it immediately. You can commit as many revisions as you want, and compare to other revisions on the branch. When you have access to the main repository again, it is trivial to merge your changes back into the mainline: baz switch arch@example.org/modulename--devel--0 baz merge joe@example.com/modulename--devel--0 fix conflicts, if any exist, and mark them resolved baz commit -s 'merge changes from joe@example.com/modulename--devel--0' You can then ignore the branch in the joe@example.com archive, or continue to use it. If you want to continue working on the branch in that module, it is a simple matter to merge from the arch@example.org archive first to pick up the changes made while you were disconnected. Distributed Development In a distributed development environment, there is no main branch. Instead, each developer maintains their own branch, and pulls changes from other developers' archives. A few things fall out from this model: To start working on a distributed project, you need to branch off from another developer's archive. This can be achieved using the same instructions as found in the "disconnected development" section above. In order for other developers to pull changes from your archive, they will need to be able to access it. This isn't possible if it only exists in your home…