monotone plugin for indefero (updated)

I’ve started hacking on a monotone plugin for indefero – a source code / project management tool which supports various SCM backends. You can find the code for it on github (git, because, well, indefero uses git…).

While there are a couple of web-related tools for monotone, namely TracMonotone and ViewMTN, both projects haven’t seen many updates over the last couple of years and are now even maintained by a single person who has not much time either. Having very good and broad tool support is however crucial for an SCM system, because only very few people are willing to use the command line for everything, so I hope that the addition of indefero as tool which will support monotone in one of its next versions will help both projects a little.

The code is still in alpha state, but one can already browse branches and revisions. My current TODO is as follows:

  • finalize the implementation of the changelog view done
  • make branch names shorter in the UI so they don’t overlap with the tree contents done
  • add automate stdio support for the SCM backend class, so we don’t need to create a separate process for every data request done
  • add automate remote_stdio support (possibly by adding a configuration option which allows either setup)
  • truncate the log message in the tree view to a proper size
  • dynamically change the clone url to the branch which the user is currently browsing done
  • check the inTags() and inBranch() implementations – apparently this does not work as it should done

Especially the multi-project nature of indefero requires some additional hacks in monotone and also one of its tools, usher (which is able to serve multiple distinct databases over one connection), so this plugin project really drives a lot of development. If you’re interested in either part and want to team up, drop me a note 😉

openSUSE build service automation

A few weeks ago I’ve hacked together some scripts to use the openSUSE build service as platform for nightly builds. The build is kicked off every hour when something new can be build.

Additionally I’ve created a small PHP client which queries the openSUSE RESTful API and shows packages, binaries, the build log of the last build and a build history.

The code for this is GPL’d and can be cloned via monotone:

$ mtn clone thomaskeller.biz biz.thomaskeller.monotone-nightly

All this could be polished and secured quite a bit more and its even arguable if its a good idea to “misuse” the openSUSE’s infrastructure
for nightly builds like this, but I see it more as a proof of concept. Since their build infrastructure code is open source as well, somebody
can always just setup a build server together with a service and a couple of predefined XEN images and should be good to go.

The concept can now be horizontally applied to other distros and versions as well, basically anything what can run within a Xen instance
(unfortunately this does not include Mac OS X or Windows, so there is still the need for some kind of alternative build infrastructure). I
eventually plan to add a couple of more Xen instances to my project and try to get them build – of course you can be my guest and play with it yourself and lend me a helping hand here 🙂

guitone 1.0rc2 released

I’m proud to announce the immediate release of guitone-1.0rc2. This is the second release in a series of smaller releases which aims at the stabilization of the guitone codebase. A lot of bug fixes went into the code, only a few outstanding issues remain. The addition of an
annotation view is the most visible new feature of this release. Please test and report bugs if possible.

The complete list of changes is written down in the NEWS file as
always. I’ll try and prepare a Windows binary tomorrow, a binary for Mac OS X should arrive shortly as well.

monotone 0.47 released

The monotone team is proud to announce the release 0.47 of our beloved version control system! This release features many bugfixes, a new translation (Portuguese) and major performance improvements for projects with larger trees. A complete list of changes can be found in NEWS.

You can grab it at the usual location – binaries are posted there as they come in.

Thanks to all people who made this possible!

guitone 1.0rc1 released

I’m proud to announce the immediate release of guitone-1.0rc1. This is the first release in a series of smaller releases which aims at the stabilization of the guitone codebase. Many (if not most) of the features one would consider needed for a “1.0” release have been implemented, a couple of outstanding bugs (noticable FS#39, FS#41 and
FS#42) have to get fixed beforehand though before that happens. Please test and report bugs if possible.

Outstanding news of this release:

  • Synchronization with other monotone nodes is no possible
  • Workspace action implementation almost feature-complete (add, drop, revert, rename, ignore, unignore and update finally work)
  • guitone can now create new monotone databases and setup new projects
  • Much improved key management with the ability to change the passphrase of keys, filter the key output and also drop keys
  • Many more bugfixes and smaller improvements as well as stabilization of the codebase

For a complete list of changes please check the NEWS file. I’ll try and prepare a Windows binary in the next couple of days, but probably won’t get to that before Wednesday, so if you want to help out, drop me
a note. A binary for Mac OS X should arrive shortly as well.

monotone 0.46 released

The monotone developers are proud to announce the release of version 0.46. The highlights in this release are bisection support – thanks to Derek Scherger! – and the possibility to call the automation interface over the network – thanks to Timothy Brownawell!

Please note that stdio interface has been changed in an backwards-incompatible way. More information can be found in the documentation and in an earlier blog post of me.

Thanks again to everybody who made this release possible! Grab it while its hot – MacPorts already has the new version and other binaries should follow shortly after this announcement.

monotone automate stdio overhauled [Update]

Yesterday my “automate-out-of-band” branch finally made it into monotone’s trunk. This is a prerequisite for the support of netsync commands in guitone I’ve blogged about earlier, as it makes in-stream informational, error and ticker messages possible, even for remote connections!

While I was at it, several other small things have been changed in stdio – f.e. the error code is now only issued once as payload of the ‘l’ stream-, which mean unfortunately that monotone 0.46 will break compatibility with clients which only understand the pre-0.46 output format. To avoid another hard break like this in the future, a new header section has been added to both stdio’s and the first header which is issued there is the “format-version” header:

$ mtn au stdio
format-version: 2

[...actual output...]

`stdio-version` is promised to stay constant as long as the output format doesn’t change and will be incremented by ‘1’ if there is any other major dealbreaker in the future. This is actually different from the `interface_version` number we also have in the automate interface, whose major number will raise everytime an incompatible change is made to any automate command. We’ll possibly change this behaviour to something more client-friendly in the future, but there is no ETA on this yet, as the current system is still good enough.

All changes for (remote) stdio will be clearly documented in the manual once 0.46 is out. Before this release happens though, I plan to finish the “automate-netsync” branch as well… Holiday time is hacking time 🙂

[Update: It was decided to name the version header “format-version” instead of “stdio-version”; I’ve updated my example accordingly]

monotone-viz [updated]

I’ve recently packaged monotone-viz 1.0.2 for MacPorts (and soon also for openSUSE), a program to display monotone’s DAG of revisions and their properties. This becomes very handy if you need to do a complex (asynchronous) merge or you want to know what exactly monotone has merged together for you. One example is the graph of the “merge fest” we’ve had in spring 2008 for the last summit you see on the right.

complex merge in monotone

(Source: monotone website)

Merging in monotone is actually quite robust; while I’ve had a lot of “fuzzy” feelings in the past when doing complex merges with subversion or even CVS, merging in monotone is a no-brainer. It most of the time does exactly what you want it to do. One exception here is the handling of deleted files however, also known as “die-die-die” merge fallout: If you merge together two distinct development lines where one file has been edited on the left side and deleted on the right side, the deletion always wins over the edit, and there is absolutely nothing you can do against it (well, despite re-adding the file after merge and loosing the file’s previous history). Thankfully this is not such a common use case and keeping an “Attic” directory where deleted, but possibly revivable files reside is the medium-term solution, until someone picks up the topic again.

But back to monotone-viz, I couldn’t fix one problem with monotone-viz on MacPorts: It doesn’t properly draw the arrows on the graph, but rather puts them above the revisions, like this:

monotone-viz-drawing-bug

I’ve already asked the author about it, but he couldn’t find out whats wrong, so I suspect something is wrong with my gtk+ setup. If you have a hint for me where to look at, give me a pointer, I’d be very thankful. And if you tell me that it works correctly for you, then even better, drop me a note as well. I’ve uploaded a test monotone database with a simple merge to test the behaviour. Thanks!

[Update: As this bug points out the render problem comes from Graphviz’ dot program – hopefully the patch will made it into a new release shortly.]

monotone / guitone update

Thanks to Timothy (and probably also thanks to the bad weather) we’ve seen some development activity for monotone recently. It started out with the “key-by-hash” changes: keys are no longer identified by its name, but their unique ID which finally solves the “I have lost my monotone private key – help!” issues from the past. This already went into monotone 0.45 which was released about a month ago.

Now the upcoming monotone release includes another long-awaited feature which is in the trunk as of yesterday: being able to query database contents from remote monotone servers. This is particularily useful if you want to check what branches are available server-side before you fetch them all. I’ve teamed up with Timothy and made a “single-shot” version of his new `automate remote_stdio` command which can be used as follows:

 # this picks your default netsync server stored in the database
 $ mtn au remote branches
 # ... alternatively, give it an optional hostname
 $ mtn au remote --remote-stdio-host myserver.org branches

Since both `automate remote_stdio` and `automate remote` can execute any available remote automate command through this, a little lua guard was implemented which allows the server administrator to pick certain commands which he wants to make available. By default, no command can be executed:

function get_remote_automate_permitted(key_identity, command, options)

where `key_identity` identifies the calling user, command points to a table which contains the command’s name and arguments, and options points to another table which contains the options for the given command.

Now what has all this to do with guitone?

Especially the changes in 0.45 forced me already to pick my old pet project up again, because key-related commands changed their output in an incompatible manner and therefor my code needed to adapt to that as well. I’m also planning to finalize other features in the upcoming weeks, amongst that netsync support (whose automate versions incidentally have to be implemented in monotone at first as well), an improved changeset browser and probably other minor things and bugs which have been on hold since February.

Netsync dialog

The next guitone version won’t be out before monotone 0.46 hits the streets though, simply because I have to wait (and implement) a couple of things in monotone first and because I want to publish a release which does not explode the first time you’ll look at it. But hey, since I’m the release manager for monotone as well, its in my hands when it will be out 🙂
Its also likely that I’ll introduce a beta release cycle for the next guitone release and make a couple of binaries so people get their hands on it easier and earlier.

So, stay tuned for more updates on both projects!

Development of guitone has been abandoned

For several, mostly personal, reasons the development of guitone has been abandoned. There are a couple of unfinished features and bugfixes waiting in the trunk which are now not released, but I’d rather want to make a major release than another minor one and there is way too much left to do for a single person with way too little time to really make a sound release.

Maybe I’ll pick it up again in a few months, but I can’t guarantee that. For now, my thanks go to all the users and packagers for their time and for the support!