Now monotone (from 0.99 onwards) gained a new commit hook which is called before the commit message processing takes place, but after the logic validated the changeset and branch to which it should be committed. Its named simply validate_changes and takes two parameters, the revision to be committed as full text (parsable in the hook via parse_basic_io) as the first and the name of the branch to which the revision should be committed as the second. Just as validate_commit_message, it is expected to return a tupel containing a boolean which denotes if the change is valid or not and an optional string which explains the reason if not and which is displayed to the committer afterwards.

With this new installment, it should feel natural e.g. to create a pre-commit hook which ensures that none of the patched or added sources contains Windows line endings:

function validate_changes(revdata, branchname)
  local parsed = parse_basic_io(revdata)
  for _,stanza in ipairs(parsed) do
    if stanza.name == "add_file" or
       stanza.name == "patch" then
      local file = stanza.values[1]
      if not guess_binary_file_contents(file) then
        local fp = assert(io.open(file, "r"))
        local contents = fp:read("*all")
        fp:close()
        if string.find(contents, "\r\n") then
          return false, "CRLF detected"
        end
      end
    end
  end
  return true, ""
end

Unfortunately its not yet possible to call mtn_automate, the lua interface to monotone’s automation commands, from hooks like this. Then we could have saved the read("*all") call and would only have to scan the output of automate content_diff, which should be a little faster than doing a full string search in lua for bigger files. We, i.e. the monotone devs, are aware of the problem though and will come up with a solution sooner or later.

I hope this new hook will still be useful for some of you until then.

The plan is to do basic first level support on this list and move developer-relevant parts via cross-posting over to the old monotone-devel list. While I’m already subscribed to the new list, I encourage a couple of other developers to subscribe there as well, in case I’m not available.

I also registered monotone-users and the pre-existing one for the Debian packaging team on Gmane, but it will take a bit more time until they set them up over there, so please be patient.

The final version of guitone will probably take a little longer, since I want to synchronize this release with the release of 0.99 / 1.0 of monotone, so stay tuned. Other development continues in the meantime, I’m currently working on including support to query remote databases from guitone, which will likely make it into guitone 1.1.

This release comes with dozens of bug fixes – a fall-out of joint efforts during a bug hunt fest earlier this year – and some interesting new features, such as an improved changelog editing view and new database management features.

Please check as always the NEWS file for a detailed list of changes and improvements. Binaries will be posted as they come in and will be retrievable from the Downloads page.

For the next version of monotone expect further stabilization work and UI improvements as well as completed localizations. We plan to make another minor release and are approaching 1.0… finally!

Right now monotone ships with five active translations, Swedish (maintained by Richard Levitte) , Italian (maintained by Lapo Luchini), Spanish (maintained by Nicolas Ruiz), Portuguese (maintained by Américo Monteiro) and German (maintained by myself, Thomas Keller). Especially the first three maintainers are currently a bit behind and short on time, so if you are capable to help out, just drop me a note or send a message to monotone-i18n@nongnu.org.

We also have two more “inactive” translations, French and Japanese, lurking around in our source tree which you could pick up and complete, but its a bit more work to finish these.

Beside that you can also start with a completely new translation and I’d be happy to assist you with everything you need for that. Again, just drop me a note or send a message to the group, we’ll quickly set you up!

I would like to announce the 0.70 release of mtn-browse:

Monotone browser (mtn-browse) is an application for browsing Monotone VCS databases without the need for a workspace. The interface allows one to:

• Easily select a revision from within a branch
• Find a revision using complex queries
• Navigate the contents of a revision using a built in file manager
• Display file contents, either using the internal viewer or an external helper application
• Compare the changes between different revisions or versions of a file either using the internal difference viewer or an external application
• Find files within a revision based on detailed search criteria
• Display file annotations and easily refer back to the corresponding change documentation
• Save files to disk
• Browse remote databases via the netsync protocol
• Support for Monotone version 0.35 up to 0.47
• Extensive built in help
• In English with additional German locale

This version brings many bug fixes and locale support improvements along with support for the newer versions of Monotone. The source can be downloaded from here.

Monotone::AutomateStdio is an object oriented Perl library module that allows Perl applications to easily interface with Monotone’s automate stdio interface. This library supports Monotone versions 0.35 up to and including 0.47. All of the automate stdio functions are available via this library. The source and documentation can be downloaded from here.

Both projects currently support Linux and Mac OS X, but should also work on Solaris and other Unixes. They are considered stable (well at least by me) so let me know if you run into problems.

Keep up the good work, Tony!

The Tarball and a Mac OS X disk image can already be downloaded at the usual location, the Windows installer will follow shortly. [Update: The Windows installer has been added.]

As always, please report bugs if possible. And while guitone now comes with one new translation, Portuguese, thanks to Américo Monteiro, I’m still looking for more translators – if you’re interested, drop me a note!

If you work with monotone you know that it has a strong concept of keeping workspace and repository distinct from each other, unlike for example git, where you can accidentially destroy unpushed changes if you remove your workspace. On the other hand separate databases make monotone workspaces also very lightweight, because checking out a new feature branch is a matter of seconds with an existing database.

Regular monotone users also keep separate projects in separate databases, because that eases the synchronization with other nodes (you don’t have to define complex include / exclude patterns for this then). But they may now face the problem that they have many databases with even more checked out workspaces in different places. Questions like “Uh, have I pulled this already? Where is my workspace again…? What branch is checked out there again…?” may arise – and working with long relative or absolute paths to use the correct database is not easier as well.

Monotone for the rescue! In the upcoming release monotone offers a way to manage regular databases in pre-defined places and allows access to these databases only by giving the file or base name as an argument for the --database option. Additionally, a new command mtn list databases (or mtn ls dbs for short) lists all available databases and shows the known workspaces of these databases.

Give me an example, already!

Lets do an example and create a new project:

$ mtn setup -b my.test.branch test-branch
mtn: initializing new database '/home/thomas/.monotone/databases/default.mtn'

The default locations where monotone looks for managed databases is configurable through another hook, named get_default_database_locations. This hook defaults to %APPDIR%\monotone\databases on Windows and $HOME/.monotone/databases on Linux.

If you now look at _MTN/options of your new workspace, you’ll see that the database option does not contain an absolute path, but a so-called alias which is used by monotone internally to look up the actual location of the database:

$ cat test-branch/_MTN/options
database ":default.mtn"
  branch "my.test.branch"
  keydir "/home/thomas/.monotone/keys"

$ mtn ls branches -d :default.mtn
$ mtn ls branches -d :default
$ mtn ls branches -d ~/.monotone/databases/default.mtn

Where are my workspaces?

Now as promised monotone is also smart about knowing what workspaces you have created for a particular database. Whenever the database option of a workspace is changed, it removes the workspace path from the old database and adds it to the new one.

Lets look at the current output of the new list databases command:

$ mtn ls dbs
:default.mtn (in /home/thomas/.monotone/databases)
    my.test.branch (in /home/thomas/test-branch)

$ mtn db init -d :test
$ cd test-branch && mtn status -d :test
[... output of mtn status ...]

$ mtn ls dbs
:default.mtn (in /home/thomas/.monotone/databases):
        no known valid workspaces
:test.mtn (in /home/thomas/.monotone/databases):
        my.test.branch (in /home/thomas/test-branch)

$ ( cd test-branch && mtn unregister_workspace )
$ mv test-branch my-test-branch
$ ( cd my-test-branch && mtn register_workspace )

$ mtn ls dbs
:default.mtn (in /home/thomas/.monotone/databases):
        no known valid workspaces
:test.mtn (in /home/thomas/.monotone/databases):
        my.test.branch (in /home/thomas/my-test-branch)

While I scrolled down their lengthy list of recipes (they call it “formulas”), I recognized that somebody was already so nice and created such a formula for monotone there.

So if you dislike MacPorts or Fink for some reason, you might want to look into Homebrew instead.

I won’t bore you with all the nitty gritty details, instead I show you the highlights that will arrive in the upcoming version 0.48 as fallout of this bugfest:

• mtn ls tags will be able to show the branch name a tag is on
• netsync commands will gain a new `–anonymous` option to enforce anonymous pulls and clones
• a new `undrop` command which recreates formerly dropped files while keeping their contents in-tact
• head-changing commands like pull, merge, propagate, disapprove and others will get a new `–update` option, which changes an underlying workspace to the new head revision
• monotone now prints out warnings in a couple of places if you’re about to create divergence, f.e. by disapproving an old revision
• diff output will now track renames and will also list file deletes

We’re planning to hold off such a bug hunt day or “hackfest” every few months, while keeping the balance between too less and too often. If you’re interested and want to join, drop me a note, idle in monotone’s IRC channel or subscribe to our mailing list. Looking forward to hear from you