Sam Wilson's Journal

A new cafe, on the way home from a ride this morning: the Mocca Lounge, it seems to be called. I guess they mean brown and not quite one thing nor another, but at least relaxing. It’s a reasonable place to sit for a while and read a book. It’s an inside cafe with no windows (can you believe such a thing?!), but it is at least dim and carpeted and large and mostly empty, which are good things. And I’ve a coffee and a book and time, which are also good things.

So, three cheers for all that, then.

I’ve been sorting out a new filesystem nomenclature, these last few months…

1. The top level (my home directory, /home/sam) contains one directory per year and ~/tmp, and a pile of other stuff, as usual, but that’s all maintained by various programmes and the OS.

   ~/
       1995/
       1996/
       …
       2011/
       2012/
       tmp/
   

2. Each year has only a single level below it, topically- and old-fashionedly-named to maintain alphabetical sorting:

       2011/
           Subject, clarification/
           Subject, andother aspect of it/
           Another subject/
           Again, something else/
   

   There are no files at that level, only directories.

3. At the turn of the year, items which are of continuing activity are moved to the new year. All else stays put. This means that the current year only ever contains things that are useful and whatever is old but still needs to be kept—and which will rarely be looked at—disappears out of sight in the old years.

   I’ve always found it annoying that computer organisation systems don’t allow things to moulder away in boxes in sheds (as it were), instead forcing everything to be current and visible — and thus liable thrown away once no longer useful. A core part of my archival system is to hide things from my own penchant for disposal.

4. Within each item, and within the tmp directory, there is no prescribed ordering. Files take whatever names and arrangements as seem suitable.

5. File and directory names contain whatever characters they want, with the exception of quotation marks, slashes, colons, asterisks, octothorpes, and anything else I think is likely to be annoying in scripts, moving between filesystems, or other filename handling.

6. There is no rule six. :-)

[Keywords: cycling, digitisation, files, filesystems, Mocca Lounge, nomenclature, organisation] [No comments] [Permanent link]

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.

[Keywords: code, externals, Project Management, revision control, Subversion] [No comments] [Permanent link]