Use SVK to remotely “svnadmin dump” an SVN repository

One of the nice things about SVN is how easy it is to carry the complete SVN history from one server to another: “svnadmin dump” produces a single (large) dump file with the complete history, then “svnadmin load” to recreate it on the new machine. However, for a handful of our projects we have an SVN repository hosted on a machine where we don’t have shell access to run svnadmin.

After considerable Google searching, I found that SVN itself offers no way to do this; svnadmin takes these parameters:

svnadmin dump path-to-repos

and only works on local repositories. I found some mailing list discussion about it, but unfortunately it was of this form:

user: “I’d like to do X”

developer: “You don’t need to do X, it works like Y”

Fortunately, this post from Thomas Mølhave explains how to use SVK to accomplish something pretty close (though not quite) to this. It was quite easy on my Ubuntu test machine:

apt-get install svk (if you don’t have SVK yet)

or

rm -rf ~/.svk (if you have SVK, but don’t care about your current stuff)

or

mv ~/.svk ~/old.svk (if you have SVK, get your current config out of the way)

then:

svk ls https://your.svn.URL/here/

svk will prompt you for all the bits of info needed to mirror the SVN repository to your local SVK storage, then list the top level files/directories. Next, take advantage of the fact that SVK uses SVN’s underlying storage mechanism, and dump that local SVK mirror, skipping revision 1 which contains SVK metadata:

svnadmin dump -r2:HEAD ~/.svk/local >something.dump

This dump can now be restored elsewhere with “svnadmin load”. Unfortunately the pathnames in it will be mangled, with the original SVN repository hostname and path prepended. For my purposes, this didn’t matter, as I only needed to make it available for occasional reference. You could of course use “svn mv” to clean it up.

On a broader note, SVK looks like a very fine distributed source control tool. On a single developer project I recently droppen SVN in favor of bzr, a distributed source control tool; one of these days I will choose such a tool for a larger project.

Update: I discuss another method for remote SVN backups, svnsync in a later post.

Selling your Software as a Service: Notes and Audio

At the St. Louis Code Camp on May 5, 2007, I gave a talk on Selling Your Software as a Service, in which I discussed our experiences selling a complex (Java) “enterprise” application in that manner. The room was much more crowded than I expected, it was exciting to have an eager group. As with all my recent talks, I used a handout instead of slides. You can download a PDF of the handout (one page, one side), or read the contents below.

The 1 hour audio recording (Olympus WS-100 digital voice recorder, Audacity cleanup) is available here: SAASTalk.mp3

A transcript of the talk is available. In the talk I mentioned Paul Graham’s The Other Road Ahead, which is shorter and easier to read the my talk transcript.

A couple of people at Code Camp asked if I could come give a similar talk in-house at their firms. Yes – please contact me with the contact form to arrange a date.

The handout contents follow.

Continue reading “Selling your Software as a Service: Notes and Audio”

Excellent JavaScript talk from Yahoo

Over at Yahoo Video you can watch an excellent talk by Doug Crockford on JavaScript (part 1). (part 2, part 3, part 4) This is likely the best introduction to JavaScript I have seen, and worthwhile even if you’ve been using JS for years.

Why does JavaScript matter?

1) It is ubiquitous now (in nearly every browser, in Flash as ActionScript, etc.)

2) It is likely to be the default choice for building scriptable Java applications, due to the Rhino JS interpreter “in the box” in Java 1.6

Update: These videos are more conveniently all on one page here.

High Quality Screen Recordings

At Oasis Digital we’ve found that we can communicate effectively with each other and with customers, across time and space, using screen + audio recording (also called screencasts or screen videos). We use these to demonstrate a new feature, to explain how code works, to described how a new feature should work, etc. The communication is not as good as a live, in-person meeting/demo, but the advantages often outweigh that factor:

  1. No travel.
  2. No need to syncronize schedules.
  3. The receiving person can view the recording repeatedly, at their convenience.
  4. Customers and develoeprs who join the project team later, can look at old recordings to catch up.

It turns out that I am unusually picky about the quality of such recordings; I’ve written up some technical notes on how to get good results, and posted them: HighQualityScreenRecordings.pdf.

A few highlights:

  • A reasonably fast computer can both run application and record screen video at the same time; but if you will be recording the use of an application that generates a lot of disk activity, you must save the video to separate hard drive (internal, external, network server, etc.) from the hard drive you are running your OS and applications from. (For applications that generate little disk activity, a single system hard drive works fine.)
  • Use a headset-style microphone, and record in a quiet place: close the door, turn off the music, etc.
  • Adjust your audio levels well. Please. This is the most common and most annoying problem with screencast and podcast recordings I find.
  • Bytes are cheap; use a sufficiently large window and sufficiently high bitrate.

Many more details are in the PDF linked above.

St. Louis Code Camp, May 5 2007

It’s time for the second (annual) St. Lous Code Camp on May 5, 2007. There’s no actual camping (unlike some other ___ camps out there), just one day of sessions. Think of it as a mini-conference. See Brian’s announcement for more details. If you’ve been thinking of giving user group talks and never gotten around to it, Code Camp is a great place to start.

I’m in for two sessions this year, assuming enough slots are available for both: Continue reading “St. Louis Code Camp, May 5 2007”

A utility bill worth looking at?

Here in Dardenne Prairie, MO (a suburb of St. Louis; see what WikiPedia has to say about it) our electricity is supplied by the Cuivre River Electric Cooperative. CREC surprised me this month with a genuinely informative addition to the data on the bill: a graph of usage over the last year.

My expectations of utility companies, most of whom operate as monopolies, have not been high. CREC, though, in addition to do a good job supplying electrical power (without the long outages that have plagued the next county over), supplies data which may help me figure out how to consume less of their product!

Of course I already knew we use far more power in the summer than in the winter; but to quantify that amounts I would have needed to sift through a pile of old bills. Seeing this chart, I wonder why our baseline (winter) usage is so high; I’m inspired to get out my Kill-A-WATT and investigate.