Posts Tagged ‘darcs’

A bit of Postfix and Darcs

Wednesday, July 14th, 2010

Somehow the official Postfix documentation continues to be intractable for me. The whole reason for getting Postfix up and running on my local machine was because of Darcs. Darcs — one of many distributed version control systems, but possibly the only one written in Haskell and intrusively interactive — likes to send patches by email. It just uses the local MTA for that, so I needed one. Setup is slightly complicated by the situation my home workstation is in: while I have a domain I’d like to use for email going out of my house, I’m on a DSL line with outgoing SMTP blocked except to the DSL provider, and my local usernames don’t match the email addresses I’ve created.

So, basically I want to send all locally submitted mail to my DSL provider’s SMTP server, with the right domain attached, without my hostname, and I want to re-map my usernames. I didn’t manage to distill this from the actual Postfix Standard Configuration Examples, but Ralf Hildebrandt’s configuration examples do have the right stuff. The only change I had to make was for the username re-writing; instead of virtual_maps (since superceded by virtual_alias_maps), I used canonical_maps = hash:/etc/postfix/canonical, which maps user and user@localhost and user@domain to email.address@domain (3 lines per user login).

Now darcs send does what it should. I can also point KMail to use local sendmail and that gets the job done, too. KMail is actually simpler, because it sets up the outgoing From and envelope addresses based on the identity in use, so it doesn’t need the rewriting at all.

I’m starting to find Darcs a little bit interesting; the idea that every patch is a branch based on what it actually needs is intriguing. Or to put it in other words: if I have one patch to file A and one patch to file B then I’ve created two branches; there’s no need to consider the two together. If I make another patch to B then that branch grows longer. My working copy displays all the changes from the branches I’m working with, that is the merge of all my branches. If I were to add a patch that changes both file A and B then the two branches merge there. Darcs uses tags to slam a line across all the files and all the patches and to merge all the open branches, which prevents a gigantic proliferation of possible branches.

The upshot is that when I do ‘darcs send’ I have the option of sending any branches I have open — and any sensible sequence of patches within the branch — so that I can very carefully upstream patches while keeping them all visible locally.

What I really miss in Darcs is some of the Mercurial workflow: seeing a graphical representation of the current branching structure (hg glog) and being able to quickly merge multiple commits into a single one for upstreaming (hg qfold). On the other hand, the darcs behavior on commit (darcs record) to ask you about every changed hunk is really nice (sometimes, at least) because it helps avoid accidentally committing debug bits or whitespace changes that you didn’t intend to do.

[[ ObKDE: and somewhere underlying this all is my need to get a Python application to talk to KWallet; why oh why didn't I have enough lunches with Richard Dale in Finland? ]]