Month: July 2010

New local pre-commit hook in monotone

There was only one hook in monotone until now which could be “reused” to interact with the commit process and validate the changeset that should be committed, the `validate_commit_message` hook. But this was a bit clumsy as it was actually designed to validate the commit message (as the name suggests) and not the changeset, thus the hook was called _after_ the commit message was entered in the editor (or was given with `–message` or `–message-file`).

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.

Mailing list roundup

I’ve just set up a new mailing list specifically for monotone users, who find the (sometimes endless) developer discussions too boring or are annoyed of ticket spam. You can find the new list’s interface here.

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.

Better late than never

ISO finally revises the voting directives for open standards after the OOXML debacle in 2007 / 2008. One of the changes is that the national bodies should no longer vote with “Yes, with comments” if they encounter serious flaws and trust on the ballot resolution meeting to get their issues solved (which evidently did not happen for OOXML), but should vote “No, with comments” instead.

Furthermore, if the “standard” receives more than 25% disapproval, it should now officially “be over” as well – if these rules would have been applied in the past, OOXML would not be an ISO certified standard as it is unfortunately today.

There are also smaller, less substantial changes. For example, the dedication to Jan van den Beld, the former head of Ecma, for his “unwavering dedication to the development and evolution of the JTC 1 procedures”, has been removed. Ironically, both Ecma and Microsoft have indeed made long-term contributions to the evolution of Fast Track in JTC1, but probably not the way they intended.

(Source)

Now the only paragraph I’m missing in the new rules obviously is a way to revoke a broken standard, but I guess this won’t happen. Lets just hope that OOXML sinks into insignificance in the next couple of years.

guitone and monotone 0.48

The current fourth release candidate of guitone doesn’t work out of the box with monotone 0.48. The reason is that the minor interface version changed slightly and my version check is too strict in this regard. But there is an option for the rescue – simply check “relaxed version check” in the preferences and guitone will happily work with monotone 0.48 and later versions, unless a major change lets something break there:

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.