I've long avoided having public comments here, for two reasons. One was that I didn't want to clutter things up to much, and another was that I was lazy about setting it up.

Today, however, I stumbled upon disqus, which does all the nifty things you might want out of a blog commenting system, all you need is to hook things up. And it wasn't even hard, and I've all the controls I might desire and stuff...

I think I'm happy with the result so far... There was some mysteries to resolve, mostly because I had hacked in some css stuff in the wrong spot, but it didn't take too long to do.

commit-patch is a cool little tool, if you want to quickly commit a patch even though the affected files are filled with other changes that you don't want to undo or commit at the time.

I recall that some people have asked if there might be some build in support for partial commits in monotone... there isn't. However, a cool little tool like commit-patch fits the job perfectly.

There is just one little problem, it doesn't have monotone support. Yet. I've added a small change that implements this and sent it to the author. If there are no issues with it, I'm guessing we'll soon see a tool that can help with partial commits with monotone.

Up until now, branch renaming has been a tricky issue with monotone... and for good reasons. What makes it tricky is that as soon as a branch has left the building (in this case, your own database) out into the world (basically, any other database), you're stuck with what there is unless you track down every damn database where it has ended up and convince every last owner of those databases to do the same change you did. That might be hard work.

So far, it has been recommended to think of what globally unique name you should use for your branch from the start, since you can't undo it later.

My question is, though, is that really true any more? After all, since that time, monotone has evolved further, new features have been added, and they might help us in this case.

Let me introduce you to this little command:

mtn suspend

This little command, which has been around since version 0.41 (September 2008), allows anyone to mark a revision as suspended, discontinued. If all heads of a branch are suspended, that branch will not be displayed any more. It will become invisible.

$ ########################################
$ # Preparations
$ #
$ mtn -d foo.mtn db init
$ mtn -d foo.mtn setup workspace -b foo -k richard@levitte.org
$ cd workspace
$ echo a > a; mtn add a; mtn ci -m "initial commit"
mtn: adding a to workspace manifest
mtn: beginning commit on branch 'foo'
mtn: committed revision bb0a1222004d13502ff27be2c92fbe6cb3f7ebf2
$ ########################################
$ # Done with the preparations
$ #
$ mtn ls branch
foo
$ mtn suspend w:
mtn: expanding selection 'w:'
mtn: expanded to 'bb0a1222004d13502ff27be2c92fbe6cb3f7ebf2'
$ mtn ls branch
$

Now, if you commit a new revision on a branch where the head is suspended, that branch will reappear.

$ echo b > b; mtn add b; mtn ci -m 'b' b
mtn: adding b to workspace manifest
mtn: beginning commit on branch 'foo'
mtn: committed revision fc6c73dc99a8f71350507a5369bdd0fa93664b41
$ mtn ls branch
foo
$

However, if you commit that same new revision with a new branch name, the old branch (whose head is the parent of the newly committed revision) will remain invisible, while the new one appears, with a history that goes back into the old (now invisible) branch.

$ # This example is instead of the previous commit
$ echo b > b; mtn add b; mtn ci -b bar -m 'b' b
mtn: adding b to workspace manifest
mtn: beginning commit on branch 'bar'
mtn: committed revision fc6c73dc99a8f71350507a5369bdd0fa93664b41
$ mtn ls branch
bar
$ mtn log --no-graph
----------------------------------------------------------------------
Revision: fc6c73dc99a8f71350507a5369bdd0fa93664b41
Parent:   bb0a1222004d13502ff27be2c92fbe6cb3f7ebf2
Author:   Richard Levitte <richard@levitte.ord>
Date:     02/28/11 08:32:41
Branch:   bar

Changelog: 

b

Changes against parent bb0a1222004d13502ff27be2c92fbe6cb3f7ebf2

  added    b

----------------------------------------------------------------------
Revision: bb0a1222004d13502ff27be2c92fbe6cb3f7ebf2
Author:   Richard Levitte <richard@levitte.ord>
Date:     02/28/11 08:31:19
Branch:   foo

Changelog: 

initial commit

Changes

  added    
  added    a

$

Another way to achieve the same effect without committing something new is, of course, to simply add another branch cert to the revision you just suspended.

$ # This example is instead of any of the two previous commits
$ mtn cert bb0a1222004d13502ff27be2c92fbe6cb3f7ebf2 branch "bar"
$ mtn ls branch
bar
$ mtn log --no-graph
----------------------------------------------------------------------
Revision: bb0a1222004d13502ff27be2c92fbe6cb3f7ebf2
Author:   Richard Levitte <richard@levitte.ord>
Date:     02/28/11 08:31:19
Branch:   bar
Branch:   foo

Changelog: 

initial commit

Changes

  added    
  added    a

$

So, this isn't reeeally branch renaming per se, but it has the same effect in practice, and it comes with the benefit that this is entirely supported by monotone, there's no need to remove a whole bunch of branch certs and add the same number of new ones, there's no need to chase down every damn database this might have spread to. There's no need for trickery.

It seems there's an annoying fault in dpkg-buildpackage, it doesn't support build-arch and build-indep in the file debian/rules. This blog entry talks about an easy way to solve this.

It seems there's an annoying fault in dpkg-buildpackage, it doesn't support build-arch and build-indep in the file debian/rules. Even when given the options to create architecture dependent binary packages only (-B) or architecture independent packages only (-A), it still insists on using the build target.

People have been annoyed at this for quite a while, considering there are a number of bug reports that have still not been resolved although this has been around for years (See bugs #218893 and #229357, but also more recently, #604397).

Debian Policy Manual, section 4.9 (debian/rules) seems to say, however, that it's perfectly acceptable to have the package built via binary / binary-indep / binary-arch:

For some packages, notably ones where the same source tree is compiled in different ways to produce two binary packages, the build target does not make much sense. For these packages it is good enough to provide two (or more) targets (build-a and build-b or whatever) for each of the ways of building the package, and a build target that does nothing. The binary target will have to build the package in each of the possible ways and make the binary package out of each.

Unfortunately, those targets are run via fakeroot, which is not recommended for configure, and sometimes not build building or testing.

So, how to solve that? There are some convoluted half ass ways to resolve this, but can it be made cleaner? Here's my attempt, entirely based on using debhelper and the script dh.

In debian/rules, disable the build target entirely, by having this as early as possible (and most definitely before the % target that's usually seen in a debian/rules that uses the command dh):

build:
    @echo 'The build target is disabled, please use the appropriate binary target.'

Add the script nofakeroot in the debian/ directory, and don't forget to make it executable. Here's what the script looks like:

#! /bin/sh

# Usage:
#   nofakeroot [command ...]
#
# Runs command after removing any trace of fakeroot from the environment it
# receives.

my_PRELOAD=
for l in $LD_PRELOAD; do
    if ! echo $l | grep "libfakeroot[-a-z]*\\.so" > /dev/null; then
    if [ -n "$my_PRELOAD" ]; then
        my_PRELOAD="$my_PRELOAD $l"
    else
        my_PRELOAD="$l"
    fi
    fi
done

was_IFS="$IFS" IFS=:
my_LIBRARY_PATH=
for p in $LD_LIBRARY_PATH; do
    if ! echo $p | grep "/libfakeroot\$" > /dev/null; then
    if [ -n "$my_LIBRARY_PATH" ]; then
        my_LIBRARY_PATH="${my_LIBRARY_PATH}:$p"
    else
        my_LIBRARY_PATH="$p"
    fi
    fi
done
IFS="$was_IFS"

LD_PRELOAD="$my_PRELOAD" LD_LIBRARY_PATH="$my_LIBRARY_PATH" eval "$@"

Finally, add a few overrides in debian/rules:

override_dh_auto_configure:
    debian/nofakeroot dh_auto_configure

override_dh_auto_build:
    debian/nofakeroot dh_auto_build

override_dh_auto_test:
    debian/nofakeroot dh_auto_test

The entire debian/rules looks like this:

build:
    @echo 'The build target is disabled, please use the appropriate binary target.'

%:
    dh $@

override_dh_auto_configure:
    debian/nofakeroot dh_auto_configure

override_dh_auto_build:
    debian/nofakeroot dh_auto_build

override_dh_auto_test:
    debian/nofakeroot dh_auto_test

I've finished packaging usher... at least the upcoming 1.0 (which comes as 1.0~dev for now). Some have asked me if I can backport it to usher 0.99, and sure, I certainly can. There are two ways to do that, one is to have the tool usherctl (which is part of 1.0~dev but not 0.99) be part of the debian package, or do things a bit differently (and quite hard-coded, I might add. Still, it's quite possible to do). Choices, choices, both are ugly, just from different points of view, but may be worth it.

I've updated my list of things to do.

Working out some code to make your blog nicer, easier to work with, or something else is a bit of a privilegde, and a good reason to run it on your own server.

The change I did this time is invisible to you, and involves loading the tags cloud (over there to the right)... before my change, it was really an integral part of each page, which meant that whenever it changed, every page was rebuilt (it's comparable to throwing away your cache, except more time consuming). I changed the whole thing so the tags cloud is now in its own file, and is loaded by every page using php's include_only. Voilà, much less rebuilding!

For monotone v1.0, it would be nice if we actually released something that felt fairly complete. The question is, what should be included?

Right this moment, I'm looking through the contributed scripts that are packaged in the source distribution, making sure they work properly with the latest release, that they use up to date technology (let me tell you, monotone has had some cool additions lately!), things like that. Just now, I reworked the old bash completion script into a new version that gets its data directly from the current man page.

What else have I been thinking of? Well, a few things actually:

• having newer versions of buildbot work with monotone... sadly enough, it seems like the build in support is not up to date, and it seems like it's been removed from version 0.8. Since we're using buildbot for tests, we do need to have this working. this is actually pretty high priority
• packaging usher for Debian. I've started on the program itself, I still need to add the information for a server package around usher (I plan to call it monotone-server-usher).
  DONE
• Keep working on the scripts in the contrib/ directory with the intention to try to see what could become supported stuff.
• Finish up the bugfix I worked on during the last bugfest.

The list could probably be made longer. Any ideas or wishes? Please email me.

Update 2010-12-03 (1): I've now done what's needed to package usher 1.0~dev. Well, ok, except there's still no manpage for usherctl, but that's a relatively small thing...

If you follow what's happening with monotone, you've probably seen that there's been some major development lately, and that we're getting much closer to a version 1.0. As a matter of fact, 0.99 is more or less to be seen as a pre-release, or RC1, or something like that.

It's full of nice little tricks that you can do to make yoru life easier. For example, to do some on-the-side processing, it's often not at all necvessary to pull a mirror of the database, as there is a mechanism to do runt remote commands (that are performed by the server, with the output being sent back to you). Mail notification scripts and other things like that have been updated to use these new features.

Just among the little cool things that weren't possible before, copying branches from one database into another, with full control over revision, the revision graph and all that, is done as simply as this:

mtn -d /PATH/TO/MY/db.mtn pull file:///PATH/TO/OTHER/database.mtn '*'

Actually, if you use monotone regularly, I urge you to try 0.99 today. It's been thoroughly tested, among other by being used live on the monotone server, and is a good way to get to know the new and changed features without having to wait until 1.0.

When is 1.0 coming out? I don't really know, but there's a desire to get it out before the end of the year. I jokingly said on the developers mailing list that we could make a Christmas release... and maybe that's a joke that'll be reality, eh Thomas (1)?

On dead fish, Thomas tells a story where Joseph Pelrine (who I understand is a fantastic coach of Scrum (development)) compared doing open source to having an affair...

... and I'm going "say what?????"

'cause I actually feel a bit insulted by the comparison, and it really does imply a kind of thinking that could be said in just a few words: "All your brain are belong to us!" (said with an ominous voice). It also implies that a company I work for has anything to do with my free time.

Mind you, I've always made it clear to anyone I've worked for that I do work with open source on my free time, and it has never been a problem, some have even encouraged me to do so on work time, for the simple reason that their benefit was greater than without it (one company was making a piece of software that was based on OpenSSL, on which I worked quite a lot at the time).

In his blog entry, Thomas gives quite a lot of good reasons why working on open source is a good thing, not just for him personally, but also for whoever he works for, in terms of knowledge he brings in to the company and the connections he makes. To that, I'll add a larger view, which is the greater good, where knowledge comes to people in a way that would be difficult otherwise. There are a lot of good programmers out there who have had a lot of training through open source, training that they would perhaps not have had otherwise. And finally, wide spread knowledge as well as all kinds of connections between people bring forward the development of humankind.

Having this reduced to an affair... I lack more words on the matter...

Not long ago, after having been served by my server for a few years, the monotone repository has moved to another server, integrated in a project infrastructure powered by indefero.

Please see us at http://code.monotone.ca/.

Not all services are up yet, it seems like buildbot's support for monotone is seriously lacking, it even seems to be removed in version 0.8, which is a bit of a pain... we're working on it, though.

More news, including a aggregation of known blogs, can be found on the main page.