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.

Have a look at the NEWS... hell, have a look at the whole site!

Next down the line for me is to have a Debian release out and to play with usher. But now, Party!

On a related note, I've promissed Stacken a lecture on March 31 (that's the last day in Q1, which I find oddly amusing). Time to prepare, I think.

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.

I've updated my list of things to do.

Of course, it's a matter of configuration, and the result I came with was to have a catch all usher server stanza in the usher configuration file:

   server ".catchall."
  pattern ""
    local "--confdir=/etc/monotone"
          "--db=/var/lib/monotone/default.mtn"
          "--no-standard-rcfiles" "--rcfile=/etc/monotone/hooks.lua"
          "--keydir=/var/lib/monotone/keys"

(The parameters following local are the same given to the server process in monotone-server)

The crucial part here is to have that empty pattern prefix, it will really catch anything that's sent to usher with the following form:

  mtn pull 'mtn://{host}:{port}?{branch1};{branch2}'

Calls that include a server name, such as the following, will match the stanza with the correspoding server name or will return an error of there is none:

  mtn pull 'mtn://{host}:{port}/{server}?{branch1};{branch2}'

Note: if your really doing this to replace Debian's monotone-server process, make sure the usher process is run by the user monotone user. It should really not be too difficult to copy /etc/init.d/monotone and change it to work with usher. I might post an usher-specific init script in another blog entry...

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...

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)?

It is tested on 4.8/amd64, but should work with -current also

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.

This means that you can disapprove bigger group of changes at once.

Of course, there are some limitations on the group of revisions. For example, there cannot be merge revisions inside the range.

This was my first bigger change to Monotone's code and along with that I gained commit access to monotone.ca, yay!.

The thing that attracted me the most about monotone was its off-line capabilities and the way it keeps track of history, which is essential to get merging working the way I want (contrary to the way I have to do it with CVS, with all the dealing with tags and all). I've also come to realise that the way it works leads to a different approach to work flow:

Maintainance branches:

many large projects that use CVS, for example OpenBSD and OpenSSL, use separate branches to maintain one or two "current" versions of the product while still being about to do "bleeding edge" development in the trunk. When you want to make a change (a bug fix), you might need to do it in a maintainance branch and then merge the results into the main trunk, which leads to the typical merge hassle with CVS. With monotone, it's a bit of a different story. First of all, you don't really have to deal with separate maintainance branches. Since a branch can have multiple heads, all you need to do it is to update to the latest release, make your change and commit, then tag it. If you want to merge the change with the other (or all the other) head(s), you simply merge. Of course, it might be more practical to have a separate branch for maintainance, but at least there is the option! There is no such option with CVS.

Looking at it as things to follow up on:

Just an hour or two ago, someone said there was a bit of an error in Makefile.am in the monotone source. I decided to take it on, and decided to do it in a slightly different way. Instead of just update to the head and make the change there, I updated to the revision where the error was introduced, made the correction, committed, which of course created a second head, and finally merged While being something of an experiment, it taught me another way to look at source development, as responses to very specific events. Basically, I treated this particular event as an email to follow up on, which creates a link between the other emailer (committer) and me, and a thread of emails (revisions) to follow. Kind of a different view, much more like people responding to each other than people dealing with a big blob called the source and whatever "magically" happens in it. A kind of social interaction between developers, maybe far away from each other.