Archive for January, 2012

Martin Pool

Improved quilt patch handling

Jelmer writes:

bzr-builddeb 2.8.1 has just landed on Debian Sid and Ubuntu Precise. This version contains some of my improvements from late last year for the handling of quilt patches in packaging branches. Most of these improvements depend on bzr 2.5 beta 5, which is also in Sid/Precise.

The most relevant changes (enabled by default) are:

  • ‘bzr merge-package’ is now integrated into ‘bzr merge’ (it’s just a hook that fires on merges involving packages)
  • patches are automatically unapplied in relevant trees before merges
  • before a commit, bzr will warn if you have some applied and some unapplied quilt patches

Furthermore, you can now specify whether you would like bzr to automatically apply all patches for stored data and whether you would like to automatically have them applied in your working tree by setting ‘quilt-tree-policy‘ and ‘quilt-commit-policy‘ to either ‘applied‘ or ‘unapplied‘. This means that you can have the patches unapplied in the repository, but automatically have them applied upon checkout or update. Setting these configuration options to an empty string causes bzr to not touch your patches during commits, checkout or update.

We’ve done some testing of it, as well as running through a package merge involving patches with Barry, but none of us do package merges regularly. If you do run into issues or if you think there are ways we can improve the quilt handling further, please comment here or file a bug report against the UDD project.

Caveats:

  • If there are patches to unapply for the OTHER tree, bzr will currently create a separate checkout and unapply the patches there. This may have performance consequences for big packages. The best way to prevent this is to set ‘quilt-commit-policy = unapplied‘.
  • bzr merge‘ will now fail if you are merging in a packaging tree that is lacking pristine tar metadata; I’m submitting a fix for this, but it’s not in 2.8.1.
  • if you set ‘quilt-commit-policy‘ and ‘quilt-tree-policy‘ but have them set to a different value, bzr will consider the tree to have changes.

To disable the automatic unapplying of patches and fall back to the previous behaviour, set the following in your builddeb configuration:

quilt-smart-merge = False
Brian de Alwis

Extracting and processing SCM data with bzr-xmloutput

I was recently asked to estimate how long I’d been working on a particular project. Unfortunately I hadn’t been keeping track of my time in any organized way.

Fortunately I realized that, since I like to commit frequently (though nothing like Stephen Turnbull’s commit-on-save!), I could come up with an estimate based on my commit dates.

But I quickly realized that bzr log --line puts the author name before the commit date:

  $ bzr log --line -r -3..
  150: Max Bowsher 2011-02-12 [merge] Fix invalid version_info.
  149: Jelmer Vernooij 2010-12-20 [merge] Fixes most of the remaining test fai...
  148: Gary van der Merwe 2010-10-20 [merge] Ignore build folder created by se...
  147: Martin 2010-09-09 [merge] Import xml escaping function through local mo...

The spaces could make extracting the date a bit fragile.

Fortunately I remembered the bzr-xmloutput plugin, which makes processing this kind of information really easy. bzr-xmloutput adds an “–xml” option to many of the standard bzr commands that encodes the output as an XML document. Combined with XMLStarlet, a command-line XML tool that provides XSLT/XPath processing (amongst other things), I was able to cook up a recipe in a matter of minutes:

  $ bzr log --xml \
  | xml sel -t -m '/logs' -m '//log' \
    -v 'substring-before(substring-after(timestamp," ")," ")' -n \
  | sort -u \
  | wc -l

The substring() is required to pull out the date; as bzr-xmloutput prints dates as ‘Day YYYY-MM-DD HH:MM:SS offset’. awk would have worked just as well too.

Too easy, thanks to Guillermo and the other bzr-xmloutput contributors! Now I’m thinking of other questions that can be answered…