This feed contains the 10 most recent pages in the "monotone" category.

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.

Posted Apr 19, 2011 9:55:22 AM +0200 | Tags: monotone

Finally, it's released. Shiny and new, I hope this will be a good one.

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!

Posted Mar 26, 2011 1:12:56 PM +0100 | Tags: monotone

We talked about releasing monotnoe 1.0 in Q1 2011, and we're currently doing what we can to make sure we release something good. Actually, as I write this, not much is happening, and I find that oddly calming, it's not like there are some last minute show stoppers (oh, that's a challenge ;-)). So, unless something big happens, I expect to see a release fairly soon.

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.

Posted Mar 20, 2011 7:00:52 PM +0100 | Tags: 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.

Posted Feb 28, 2011 8:40:35 AM +0100 | Tags: monotone

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.

Posted Dec 2, 2010 11:27:17 PM +0100 | Tags: monotone

I've started fiddling with usher on Debian and trying to figure out a good way to have it replace a bare monotone server (the way it's currently done with the Debian package monotone-server), and the big question was how to have a smooth and transparent transition.

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

Posted Nov 25, 2010 2:36:00 PM +0100 | Tags: monotone

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


  1. That's december 3rd 2010 ;-) ↩

Posted Nov 18, 2010 4:18:32 PM +0100 | Tags: monotone

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


  1. Thomas has been our release manager for the last releases. ↩

Posted Nov 11, 2010 2:45:33 PM +0100 | Tags: monotone

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.

Posted Nov 2, 2010 3:52:43 PM +0100 | Tags: monotone

I've noticed how much monotone has changed my habits and views on version control. From being a fairly mature CVS user and hacker, I've now fully moved to use monotone as much as I can. It was most noticable a couple of days ago, when I worked on some project that's still versioned using CVS, and wondered why so many files were missing, until I realised I had forgotten to update with -dP... Those flags used to be second nature!

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.
Posted Mar 18, 2006 8:02:46 PM +0100 | Tags: monotone

To see all of them, check the archive-monotone.

blog comments powered by Disqus