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.

My exim instance has sender verification enabled by default and I like it, because ~90% of the spam doesn’t even need to get scanned by spamassassin, which in return means lower server load. However, sender verification also makes problems sometimes, especially if automatically crafted emails from, lets call them “legacy”, systems should reach me. You can of course replace “legacy” with “simple PHP mail script” or “shop frontend” if you like, as administrators or developers of these systems are apparently completely unaware of the bad job they do, if they fulfil the requirement “hey, the user should get this notification email, but ensure that he won’t spam the support with questions about it, so use an invalid address…”

You know what follows: The novice, or sometimes also not so novice developer / administrator, simply goes ahead and sets noreply@host.com as From: address. Especially in shared hosting environments there is usually an MX server configured for the hosted domain which allows local relaying, so sending a mail from a PHP script like this

mail("joe@otherhost.com", "Hello", "It works!",
     "From: noreply@host.com\r\n");

seems so simple. Of course most of the time it gets completly forgotten to give the mail server of the host.com domain a notice that there is suddenly a new (bogus) mail user available within one of his managed domains! So how do you fulfil the “don’t spam the support” requirement then?

Well, the simplest way is to use an existing mail address which is known within the sending mail server and then also add a Reply-To: header to your mail which may then contain the bogus address. If the user clicks on “reply” in his mail client, this reply-to address will pop up in the To: field and you practically achieve the same effect.

But probably the best way is of course to convince your management that it should not ignore customer inquiries by stupid procedures like this…

As a customer of several online services I have encountered this and similar mail problems a lot in the past. I cannot remember exactly when I actually stopped informing the individual webmaster or support team about the problems they had with their mail setup, simply because my inquiries had been ignored most of the time. See this blog post as a silent rant for all the crappy configured setups out there.

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!

But yes, there was one task which was yet missing there – one to automatically create a Win32 installer. The steps to produce that had been so far:

1. enter the to-be-packaged version in the InnoSetup script file
2. convert the supplied text files from Unix to DOS line endings, while giving them a .txt extension
3. call the InnoSetup compiler on the script file and create the executable

Especially the first and second action looked hard to automate, given the fact that Windows does not come with a rich set of tools to process text streams – and requiring a Cygwin installation just for using sed seemed awkward to me. Obviously other people had similar problems before and somebody proposed to emulate sed with a VBScript which would be executed by the Windows Scripting Host (WSH). Wow, cool thing – if I’d just remember my broken Visual Basic knowledge. But didn’t Microsoft have this Javascript Look-a-Like, JScript? Shouldn’t this be executable as well?

Apparently it was and I sat down to hack an improved JScript sed version:

var patterns  = new Array();
var replacements = new Array();
var argcount = 0;

for (var i=0; i<WScript.Arguments.length; ++i)
{
    pat = WScript.Arguments(i).split("/");
    if (pat.length != 4)
        continue;

    patterns[argcount] = new RegExp(pat[1]);
    replacements[argcount] = pat[2];  
    ++argcount;
}

while (!WScript.StdIn.AtEndOfStream)
{
    var line = WScript.StdIn.ReadLine();
    for (var i=0; i<argcount; ++i)
    {
        line = line.replace(patterns[i], replacements[i]);
    }
    WScript.Echo(line);
}

Now the only thing what was left was to fiddle around with the WSH command line tool cscript and to combine everything for a proper QMake target. Here we go:

DOCFILES="NEWS README README.driver COPYING"
...
win32 {
    isEmpty(QTDIR):QTDIR           = "c:\Qt\4.6.2"
    isEmpty(MINGWDIR):MINGWDIR     = "c:\MinGW"
    isEmpty(OPENSSLDIR):OPENSSLDIR = "c:\OpenSSL"
    isEmpty(ISCC):ISCC = "c:\Program Files\Inno Setup 5\ISCC.exe"
    
    win32setup.depends  = make_first
    win32setup.target   = win32setup
    win32setup.commands = \
        cscript //NoLogo res\win32\sed.js \
            s/@@VERSION@@/$${VERSION}/ \
            s/@@QTDIR@@/$${QTDIR}/ \
            s/@@MINGWDIR@@/$${MINGWDIR}/ \
            s/@@OPENSSLDIR@@/$${OPENSSLDIR}/ \
            < res\win32\guitone.iss.in > res\win32\guitone.iss && \
        ( for %%f in ($$DOCFILES) do \
            cscript //NoLogo res\win32\sed.js \
                s/\n\$$/\r\n/ \
                < %%f > %%f.txt ) && \
        \"$$ISCC\" res\win32\guitone.iss && \
        ( for %%f IN ($$DOCFILES) do del %%f.txt )
    
    QMAKE_EXTRA_TARGETS += win32setup
}

So if you know enough Javascript you can probably emulate whatever tool you're missing on Win32 without having to depend on any external dependency. Very cool!

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)