Composer repository URLs can’t use UNC paths?

It would seem that when using Composer on Windows, one cannot use UNC paths as repository URLs. That is to say, the following doesn’t work:

{
  "repositories": [
    {
      "type": "vcs",
      "url": "//SERVER/Share/project.git"
    },
  ]
}

Instead, the share must be mapped and the mapped drive letter used:

      "url": "G:/project.git"

This does, of course, have the stupid side effect of forcing everyone who uses the composer.json in question to map the share to the same drive letter! However, this is hardly the most significant of the miseries that one must live through when developing software on Windows…

Backing up thunderbird email

When backing up Thunderbird, the only files I worry about are the actual mbox files that store the ‘Local Folders’ (archived) email, and the *.mab addresbook files. Everything else is operational cruft. This might seem a bit extreme—after all, why not backup the account configurations and user preferences etc.—but I jump from machine to machine often enough, and reinstall things so regularly, that setting up a few email accounts now and then is too easy, and I prefer the minimalism. This way, I know exactly what I’m backing up and where my emails are, and I’m only backing up what’s essential. I’ve tested restoring to other email clients too (like sylpheed), and all is seamless and heartening.

This minimal backup works too because I use the ‘archive’ function of Thunderbird, which is just a simple “copy to date-based (i.e. year-based) folder hierarchy in Local Folders” function, activated by pressing a. Hence, I don’t bother filing emails by topic, and I store all sent items in the same folders are those received (yeah, I’m not suggesting that anyone else is ever going to find my system at all sensible). So the files backed up are small in number and never disappear (new ones are added, is all). I don’t back up what’s still up in the IMAP server, but then there’s not much of that at any given time.

The last part of my backup is to include all the files, both mbox and mab, in a version control system (in this case, Subversion). This way, I can roll back any file to any previous revision, easily. They’re all text, so the revision space-usage is efficient and of no worry; I’m only talking about half a gig per year anyway.

The script that does all this for me is simple:

#!/bin/bash

TB_PROFILE=/home/sam/.thunderbird/po2p7m5o.default/

MBOXEN=$(dirname $0)"/mboxen"
ABOOKS=$(dirname $0)"/abooks"

echo "Copying addressbooks to $ABOOKS..."
cp -v "$TB_PROFILE"*.mab "$ABOOKS/."

echo "Copying mail files to $MBOXEN..."
rsync -rv --exclude=*.msf "$TB_PROFILE/Mail/Local Folders/Archives.sbd/" $MBOXEN

# ...Followed by a svn commit

mbox is a pretty ridiculous format, really. It’s based on the idea that it can determine the beginning of each email by the fact that the word ‘From’ starts a line and is followed by a space. That’s it! Daft. Thunderbird supposedly has some greater means of delimiting messages, but still I’ve on a number of occasions had email corrupted due to this silliness. Not hard to recover from, usually.

rsync.net

I signed up for an rsync.net account a bit over a month ago. They’re a reasonably-priced off-site filesystem provider, seemingly run by people who care about security and doing things normally. By ‘normally’, I mean rsync for starters (oddly enough, given their name) but also the whole gammut of *nix-y ways of doing things; one can interact with them with the usual tools. So they provide a proper, old-fashioned filesystem, and protect it well (there’s even a warrent canary). There’s a choice of datacentre — I chose the Zurich one — and plans ranging from 7GB (80c/GB/month) to 10TB (8c/GB/month). They even correspond via email, of all things! It really is odd that a company that behaves so normally is so uncommon…. I don’t care about pretty graphics, boring and unused extra features, or ‘enterprise-readiness’ (whatever the flip that is), I just want a share of some disk in a big strong building somewhere, one that’s going to be protected and maintained properly and simply. All I can say so far is three cheers for rsync.net. (I’ll be sure to report back if my opinion changes.)

So that’s all well and good, and I’ve got my big disk in the sky, but how am I going to use it? I am going to host a Subversion repository there, to serve as an everything-bucket. That is all. How well will svn handle a huge (multi-gigabyte) repository? I’ve heard varying reports, but most seem to think it’ll be fine. Certainly it’s data-copying system will work well, as far as resuming aborted connections goes (it’ll only copy what’s not yet been copied; much as rsync.net does (although I don’t think it does it at any smaller unit than that of the whole file)). Questions remain about how much overhead diskspace I’ll waste by doing this, but as most of the binary files will only be modified at most once or twice, and generally not at all once they’re checked-in, I don’t think it’ll matter too much.

I’ll see how things go.

Switching an SVN directory to and from an ‘externals’ definition

There seems to be quite a few posts out there about how to replace Subversion externals definitions with local directories, but not so much for going the other way. I’m not sure why; it seems to me more likely that one would start off with some small module as part of a bigger repository, and then at a later date want to move it out to live on its own. I don’t really know what I’m on about, though.

The point being, that I’m working with a branch of a project that is having a few of its directories — its current, local, ‘normal’ directories — replaced by externals definitions. That’s all fine and good, but I keep having to switch to trunk and back again, and there’s the crux: the directories that are getting turned into externals do not like being switched.

Running the usual svn sw http://svn.example.com/repo/branches/v2 from the top level of a trunk checkout gives the following error:

Fetching external item into 'lib/foo':
svn: warning: W155037: Previous operation has not finished; run 'cleanup' if it was interrupted

Running svn cleanup complains with:

svn: E155010: The node '/path-to-repo/lib/foo/file.txt' is not installable

And not even status has anything useful to say (throwing instead the same error as above).

A solution (and yes, this post is probably a bit long-winded for such a short snippet of advice; I can only say that I felt like writing this down this morning because four weeks ago I figured it out but forgot and I suspect that four weeks hence I’ll have forgotten again, and this morning is one of those moments of verbosity; blame Travels with Charley, which I was reading over breakfast this morning), and it’s probably not the ‘proper’ solution because I’m no Subversion hacker and do rather treat it as magic, but the solution that I use is (and I’d better put it on it’s own line, because no one’s likely to have read to the end of this paragraph)…

Delete the offending directory (as in, rm -r lib/foo or what have you), and update again.

That’s all.