On the definitions of terms

This morning, on my walk to work, saw a tweet in my feed mentioning a new service built on BitTorrent, called BitTorrent Sync. Fully encrypted, the blogger in question called it “Dropbox without the cloud”.

I just about tripped over my own feet.

The term “cloud” has very specific semantics in networking and computing, and it annoys me more every time I see it misused to sell something. There couldn’t possibly be a more cloud-like implementation of cloud storage than by using BitTorrent. By distributing the data all across the cloud, you really are just dropping your bits on the cloud, and picking them up later.

The Cloud, quite simply, any and all of the networks you connect to, but don’t control. Most often, network cut sheets use a cloud to represent the Internet as a whole. It’s an opaque region of the ether that may have your systems on the other side, or it might just be used to represent the source of incoming requests to your services. It may also be used to represent the networks between you and a network API with a specific, known endpoint (like, for example, Dropbox!).

Any x-As-A-Service service is fundamentally a cloud service, because it operates on on a network outside of your control. Dropbox is a cloud service. Netflix is, and you’d better believe BitTorrent is, too. Dropbox exists on a readily quantifiable set of servers, but this BitTorrent Sync product isn’t nearly so measurable—your data could literally be anywhere within the cloud.

For the sake of comparison and clarification, what would be a “Dropbox without the cloud”? A local server within your network that provides similar data mirroring. This would likely only ever be useful in an office environment full of thin clients (or tablets) where no one necessarily has the same desk from day to day. This, however, largely doesn’t exist in most office environments. I have a laptop computer at Kijiji that I bring with me when I need to work in a different room, or if I need to travel. And if, for any reason, I can’t bring the computer with me, I can access it through SSH, anywhere within the corporate network. “Dropbox without the cloud”, in our ecosystem of cheap, portable devices is fundamentally meaningless.

So please, if you&rsquo&re selling something, and want to refer to The Cloud, use the term correctly. This industry is one based on precision of language, and “cloud services” is vague enough already, without being used as its own antonym!

Abandoning commits in Subversion

Before we begin, I don’t normally keep my code in Subversion… any more. When I started at Kijiji, Subversion was our local VCS of choice until there was a organisational decision to switch to Git, and we local developers agreed that it made sense. In the roughly two years since then, I’ve become a total convert. However, I’ve continued to use Subversion for personal projects, simply because I’m the only person working on them, and in case I move from machine to machine, I want to have reasonably quick access to the code.

I have since lived to regret this decision. Despite the fact that Subversion externals work vastly better than Git submodules, there are still some things I can easily do in Git that simply aren't available in Subversion.

One of my favourite things about Git is that, as long as you haven’t shared your repository, you can really mess with history. Step back three commits in the history, branch, write a new commit, then even cherry-pick everything else back on… then reset your HEAD hard, fast-forward, and when you push, it’s like those commits never happened!

You don’t really get that option in Subversion. Since it’s a centralised repository, everything you commit goes off immediately, so good luck getting rid of it for good! So if you realise that your last two commits were completely wrong, what do you do?

Fortunately, you can still branch from your history in Subversion:

$ svn copy http://svn.example.com/project/trunk/@56 http://svn.example.com/project/branches/whoops

Your tree now looks something like this:

--55--56--57--58--59 (trunk)
       \
        \-------------60 (whoops)

Now, everything that was on trunk up to, and including, revision 56, is in the whoops branch. Update your project’s root directory (or check out the branch into a separate directory), and get back to work! Once you’re done, the challenge becomes how to squash everything on trunk since 56. This is disturbingly simple, and only incurs two commits. It sounds dangerous as all hell, but trust me on this.

You’re going to delete trunk.

Only for a second! Since you want to destroy the last few changes on trunk anyway, and replace them with what you’ve done on whoops, this is entirely safe. After deleting trunk and committing, you just move branches/whoops to trunk, commit, and you’re off to the races! The whole process looks like this:

$ cd ~/project/
$ svn copy http://svn.example.com/project/trunk/@56 http://svn.example.com/project/branches/whoops
$ svn update
$ cd branches/whoops/
... work ...
$ cd ~/project/
$ svn rm trunk
$ svn commit
$ svn mv branches/whoops/ trunk/
$ svn commit

And, at the end of the day, you get a tree that looks like this:

--55--56--57--58--59    /-- Branched here
       \               /
        \-------------60--61--62 (trunk)
                          /    \
   Deleted trunk here -- /      \-- Renamed whoops to trunk

If you need to get any of 57, 58, or 59 back, they’ll be visible from the project root. Not remotely gone forever!

And so we see that, even in Subversion, you can achieve a measure of Git-like control of your history. The only difficulty is coordinating with your collaborators, along with the obvious evidence in the history of what you’ve done!