E-Scribe : a programmer’s blog

About Me

PBX I'm Paul Bissex. I build web applications using open source software, especially Django. Started my career doing graphic design for newspapers and magazines in the '90s. Then wrote tech commentary and reviews for Wired, Salon, Chicago Tribune, and others you never heard of. Then I built operations software at a photography school. Then I helped big media serve 40 million pages a day. Then I worked on a translation services API doing millions of dollars of business. Now I'm building the core platform of a global startup accelerator. Feel free to email me.


I co-wrote "Python Web Development with Django". It was the first book to cover the long-awaited Django 1.0. Published by Addison-Wesley and still in print!


Built using Django, served with gunicorn and nginx. The database is SQLite. Hosted on a FreeBSD VPS at Johncompanies.com. Comment-spam protection by Akismet.


Pile o'Tags

Stuff I Use

Bitbucket, Debian Linux, Django, Emacs, FreeBSD, Git, jQuery, LaunchBar, macOS, Markdown, Mercurial, Python, S3, SQLite, Sublime Text, xmonad

Spam Report

At least 236562 pieces of comment spam killed since 2008, mostly via Akismet.

Obscure "svn mv" problem solved

I banged my head against this one for a while before figuring it out, so I'm posting the solution -- for my own future reference if nothing else.

I've been working on extending Textmate's Markdown language bundle. The development versions of the bundles are stored in a repository managed by Subversion.

I noticed that the bundle's name started with a lowercase letter, unlike the other bundles, so I did a quick svn mv to fix it:

$ svn mv markdown.tmbundle Markdown.tmbundle

but I got this perplexing error message in response:

svn: Working copy 'Markdown.tmbundle' is missing or not locked

I Googled extensively on "svn working copy" + "is missing or not locked" but the pages I found either referenced a bug that didn't apply to my situation (nested directories named the same as the parent) or advice that didn't solve the problem (svn revert or deleting the local copy and refreshing from the repository).

Some of the bug references made me suspicious of Subversion 1.2.x so I also tried downgrading to 1.1.x. Same problem.

I deleted the entire working copy and tried again with a fresh checkout. Same problem.

Eventually a lightbulb came on: the Mac's HFS+ filesystem is case-insensitive (though case-preserving). Subversion's "move" operation is actually a "copy" followed by a "remove" -- but on an HFS+ volume, the copy step will fail when the only difference in filenames is a case-change. Aha.

The obvious fix:

$ svn mv markdown.tmbundle Markdown2.tmbundle
$ svn ci
$ svn mv Markdown2.tmbundle Markdown.tmbundle
$ svn ci

Afterward I found an entry in the Subversion FAQ that addresses this problem, with an alternate solution that involves renaming the file on the server and then updating the working copy.

I can't believe I went through all that to capitalize a single letter. Future generations will thank me, I'm sure.

Saturday, November 19th, 2005
+ + +

Comment from Flufo , 16 months later

I think this happens when you want to change only upper-/lowercase. MacOS doesn't accept files/folder with same name but different "capitalization". Linux/Unix do.

Comment from Paul , 16 months later


Comment from fixsvn , 18 months later

This is broken behavior by Subversion, I don't care what the developers say. Allowing devs to change the capitalization of files without going through a ridiculous hassle isn't "coding around the broken behavior" of Windows or any other case-insensitive OS, (as I've once read somewhere). Case-insensitivity in an OS does not make the OS "broken".

Comment from bitmonk , 2 years later

Also keep in mind that you can format/mount a disk image or external drive as "HFS+X", rather than "HFS+J", which is the default for Mac OS X Server. All Apple Software and Cocoa-built code will work fine, as well as typical *nix software. When I met members of the Darwin / FS team at WWDC one year, they explained that Case Insensitivity is mostly for Carbon Apps, which are mostly Microsoft apps like Office X - FireFox has used Carbon apis for some time, but does not for any sort of file access.

Disk Utility will help with this. Also, if you run Disk Utility during OSX install, you can reformat your drive as HFS+X and install on it, though the installer won't give you this option - you must run DU via the Utilities menu right when the Installer boots up. I've done this with fine success, though I often forget to and when I get a new Mac, often don't want to go through the trouble.

In some situations with older cvs repositories, you'll find that you simply can't make a checkout without case sensitivity. A disk image is often useful here.

Comment from Paul , 2 years later

Excellent info, thanks.

Comments are closed for this post. But I welcome questions/comments via email or Twitter.