DITABase notes

Subject tags: 

I tried to do some work on Ditabase today. I set myself three tasks: finish a little script off which fixed the svn:content-type metadata in a remote repository (as practise for scripting the kind of SVN manipulation we’ll need to do in Ditabase proper); finish off the SVN Maypole model I’ve been writing; with that in place, generate XML directory listings of a repository to be handed off to Kupu.

I achieved none of them. I wasted a couple of hours fighting Mac::Glue, trying to restore some metadata in my iTunes library, before giving up and fighting Applescript instead. Then I tried the metadata thing. I tried what I thought was an obvious command:

svn propset svn:mime-type image/jpeg file:///home/simon/ditabase/svn/docs/image/carwash.jpg

Unfortunately, svn doesn’t support this. With some good reason: you don’t want people writing directly into the repository, because that betrays the whole point of a version control system. I thought it might schedule the change for a later commit, which would get around that, but unfortunately not: svn requires a checkout before doing anything.

I thought that was a bit silly, and wondered what svk would do with it:

svk propset svn:mime-type image/jpeg file:///home/simon/ditabase/svn/docs/image/carwash.jpg

The answer was “the right thing”: mirror the repository, make the change, and push the change back to svn as a commit. So I started converting all my code to use SVK instead. Unfortunately, after the (comparatively) brilliant SVN::Core interface, I found the SVK API a lot harder to work with. Part of this is because I am generally slow at making paradigm shifts like that; the design is quite different between the two and requires a different way of thinking. When a change like that is required, I tend to procrastinate a lot rather than get down to adjusting. Hence the fixation with my iTunes library, and the many games of chess I have played today.

I’m still not thinking in a very SVK way so I don’t know how the new model class is going to work, but I did make a few notes. One of the most annoying things was the fact that SVK is written expecting to be a command-line tool. The API stuffs all its output in an output buffer, for instance, instead of returning sensible data structures. The most obvious annoyance is the fact that it pops up little user dialogs every time it needs to know something, and the prompting is hard coded deep in core routines. I’ve been running around patching things to give me some scriptable routines instead.

Now I have to decide what to do: whether to switch the whole thing to using SVK as a backend instead of SVN, which would make some things easier and some harder, or to continue to use an SVN repository but just use SVK for the interface to it. Hopefully I’ll be able to come to it again tomorrow with a fresher perspective.