First Steps with bzr-svn

I’m an SVN nut – love it, use it, talk about it at any opportunity, can’t physically write code without it. But as a telecommuting developer who is sometimes travelling around, I’ve been thinking for a while that one of the distributed systems would really make more sense. I tried git ages ago and decided that I just wasn’t smart enough to use it; I’m so comfortable and confident with subversion and it is such a change.

I know there are alternatives out there, I saw a talk about bzr at LUGRadioLive last year and I have some canonical-associated friends who use it so I know the community is good and I can get some help if I need it. I confided in a fellow developer that I’d struggled with git, but that I’d also read that bzr would be more subversion-like which seemed ideal for me since that’s my background. His response? “No, bzr isn’t easier for people coming from SVN, bzr is just easier“. So I figured I’d give it a go.

I’m an ubuntu user so I installed the bzr, bzrtools and bzr-svn packages, and read the user guide – the user guide is absolutely excellent and I wish every tool in the world had instructions like these! Anyway here’s a quick outline of how I got started and used bzr against my existing SVN repository (it seems too much like hard work to start migrating repos before I’ve decided if I like the tool).

Who Am I?

Tell bzr your name and email so it can credit your commits to you:

 bzr whoami "Lorna Mitchell "

Good start :)

Checkout from SVN

There are several ways to set yourself up to work with bzr-svn, I chose the simplest, and checked out from SVN using bzr, then branched locally and worked on that. First we initialise a directory as a bzr repository:

bzr init-repo --default-rich-root snapshot

Then I actually did the checkout.

bzr checkout http://svn.rivendell.local/snapshot/trunk trunk

So at this point I have a current working copy of code.

Bzr Branching

So that I could work locally and commit at intermediate stages between commits to the SVN repo, I then made a local bzr branch of this checkout. This is the bit that’s a bit different to subversion, the branch is just local to you, more like a working copy. It was quite easy:

bzr branch trunk working

So I’ll now make my changes in the working branch I just created, this becomes my web root if its a web app for example.

Comitting

Using the “bzr commit” command from the branch we created (“working” directory in the examples) only commits locally to the branch. You can do this as many times as you need/want to until your feature is ready (or maybe until you can get back to a connection).

Updating

I realised at this point that I needed to update from the repo to pick up some changes someone else had made, to do this I needed to update my checkout and then pull the changes into my branch:

cd ../trunk
bzr update
cd ../working
bzr pull

To give a clearer idea of how this all goes togehter, I drew a diagram of the repo, the checkout, the branch, and how the process works to get between them all (click to see it at a sensible size):

Status

The “bzr status” command shows what changes are local to the current directory.

Conveying Changes Back To Repo

I made a couple of changes in my working directory and then wanted to put these back to the repo. So from the checkout (“trunk” directory in my example), I merged the changes in and then committed.

bzr merge ../working/
bzr commit

My changes were then in the SVN repo exactly as normal, bzr-svn means extra functionality for me but nobody else necessarily needs to change tools and all the hooks and backup routines and everything that are already in place for this repo can be kept. I’m happy with that outcome!

Next Steps

This is a very basic usage of bzr, really I’m only recording my own experience to make these concepts clearer in my own mind. I plan to do a lot more with this tool and will keep blogging as I go along. Comments, corrections, suggestions and questions are all very welcome – add a comment :)

Customising Screen-Profile Files

I wrote a while ago about the new version of screen in Ubuntu Jaunty. Screen is an application which lets you run lots of tabs inside one terminal window, then disconnect from screen and reconnect again later. You can turn on and off a whole bunch of notifications which appear inside screen, and I also added the pink tabs I used with older versions of screen.

The tabs line is the one in the profile file which starts “caption always”.

caption always "%{wk}%H%{Bk}|%{Mk}%?%-Lw%?%{km}[%n*%f %t]%?(%u)%?%{mk}%?%+Lw%? %=%{Bk}"

I also altered the “hardstatus string” line, which holds lots of placeholders, to remove the clock – I run screen on my laptop inside KDE mostly, so I already know what time it is. Annoyingly this isn’t customisable via the menus but I edited my profile file to get rid of it – here’s the diff

29c29
< hardstatus string '%99`%{= kw} %100`%112`%= %102`%101`%114`%115`%108`%113`%119`%117`%118`%116`%106`%104`%103`%105`%107`%Y-%m-%d %0c:%s'
---
> hardstatus string '%99`%{= kw} %100`%112`%= %102`%101`%114`%115`%108`%113`%119`%117`%118`%116`%106`%104`%103`%105`%107`'

The only thing annoying me now is that screen seems to constantly redraw itself, so Konsole thinks there is activity in that screen, when there isn’t. Suggestions on stopping this or more ways you can customise your screen file are gratefully received – just add a comment!

Upgrading Subversion Server to 1.5

I’m really excited about the magic merging features in the newer subversion versions at 1.5 and later. I’m still figuring out which are actually useful, more on those another day, but I wanted to mention something I ran into when upgrading my server.

Some time ago I upgraded the subversion server to subversion 1.5, and the clients that use it are probably mostly on 1.5 as well. We haven’t had any compatibility problems between versions on this upgrade, which is good news since a few versions ago there was a release which caused any newer client to render the repo unreadable by any older client. Predictably someone in the office upgraded their client one day and it took us a good few hours to work out why subversion had stopped working!

The Subversion 1.5 upgrade doesn’t turn on all the 1.5 features by default, but will upgrade to 1.5 and allow older clients to continue to work with it. If you want to upgrade to the 1.5 features though, you’ll need to make sure that all users have clients of version 1.5 or later, and then upgrade the repo by running:

svnadmin upgrade

Once this is done you can start using the new merge tracking features in subversion – enjoy!

5 Ways to Make Friends at a Technical Conference

These are my top tips for getting along and meeting new people at a technical conference.

Take an extension cable

Conferences are notorious for having too few and too short power leads, and everyone needs to recharge laptops, especially in hands-on sessions like tutorial day. Having an extension cable will make you instant friends as you bring power to more people.

Join in the pre-conference hype

Follow the nominated twitter tag and log into the IRC channel if there is one. Find out who is staying in the same place as you or arriving at the same time, arrange to travel together or meet for a pre-conference drink to break the ice.

Attend the extra-curricular events

Don’t think for a moment that when the official schedule ends, you are off-duty for the night! Find out about any social activities going on – and if there is an informal track such as an unconference, make sure you attend, or even participate. This is a great opportunity to meet more people and see more talks in a much less structured environment.

Take business cards

Or if you don’t have that kind of job (or even if you do!) get some moo cards to take with you so you can pass on your blog/email address, name and twitter details to people you want to stay in touch with after the event.

Stay an extra day

The party starts when the conference ends, so hang around for 24 hours or so and join in :) Especially for the speakers (whose rooms are paid for) and those travelling internationally, there’s no need to rush off straight away. Some of the best times I’ve had at conferences have been after the main event.

Keep in touch

Write up your experiences on your blog (do you have a blog? If not, this is a great place to start) and tag it appropriately. Comment on other people’s and stay in touch with the new friends that you made at the conference.

OK, so technically this is six ways to make friends, but I won’t apologise for that :) What’s your top tip for conference attendees?

Ubuntu Netbook Remix on Aspire One

A while ago, actually quite a while ago in May, I put the Ubuntu Netbook Remix version of Ubuntu 9.04 Jaunty Jackalope onto my lovely blue Acer Aspire One netbook.

The way this works is that on another machine (or I guess on an existing OS on the netbook) you download a bootable USB key image. With some trepidation (not a whole lot, I did back up first), I put in the USB key and settled in to see how far I could get with the installation.

Well, a short time later I realised I’d finished installing and was really just fiddling! Straight out of the box the wifi worked, the hibernate worked, sound (in and out) worked, the webcam worked, and there is this great window handler thing which amalgamates title bar and task bar into one. There’s also a cute menu on the desktop – all in all its really neat:

The working hibernate in particular has really made a big difference, at home the netbook just gets used for short bursts and lives next to my bed, usually plugged in. When it comes into its own though is at conferences! I can flip this thing open, use it, and flip it shut, pretty much all day. The startup time is really small from suspend and so long as I’m only dipping in and out (at conferences, I’m mostly in talks so I’m only ever checking mail etc), the battery life easily lasts a day.

Thanks to the Ubuntu folks – this is one quality piece of software and now I love my little netbook even more. Anyone else using the netbook remix? Were your experiences as good as mine?

Presenting with a Netbook

I’ve been giving a few talks in the last few months and I’m increasingly realising that although I love my thinkpad, its overkill for anything where I don’t really need the hardware, or where I don’t want to be carrying a full-size laptop all day. So I’m increasingly taking just my netbook, which is an acer aspire one with 512 MB of RAM, and using that along with some xrandr skills and my much-loved Kensington Slimblade Presenter Mouse (its the multimedia version, has extra controls on the underneath).

Presenting Setup

The netbook is easily up to this job – it happily runs the open office presenter program, I don’t have the presenter view plugin installed on it yet but just use the screens mirrored and use the netbook screen to see the current slide rather than having to look at the screen. This saves me either having to look away from my audience or from being completely floored by slides WAY too big for me to read when I’m standing in front of them (I presented at the FOWA roadshow, great venue but slides so big I didn’t dare look round at them!). The netbook screen is small but font sizes on slides should be quite big and I’m kind of long sighted so I can read the text at a distance of 6 to 8 feet without an issue.

The presenter mouse has a little USB dongle and then controls for controlling the presentation, with a laser pointer and a button to turn slides to black – once I begin I don’t need to be back within reach of the computer at any point. Which is really useful if you get one of those awkward spaces where the dock for the laptop is in a corner you don’t want to be standing in (I see this a lot at the informal geek events). Just start it going and get into position – and present from there. Of course this relies on knowing the presentation well enough to not need your slides or notes or having a paper copy you can refer to.

Don’t be fooled that you need great hardware or particular equipment to give a talk – anything with a monitor socket to talk to the projector is good enough, and if you can get a remote of some kind then all the better. Other accessories that might help is a stop watch (or use the timer on your phone and put it somewhere you can see it), so you know how you are doing for time, and some notes on index cards that you can easily hold without rustling. Above all, take a step away from your computer and look your audience in the eye – they’re here to see and hear you.

Version Parameters for Web Services

This is a mini series on points to consider when designing and building web services. So far there have been posts on error feedback for web services, auth mechanisms for web services and saving state in web services.

When designing a service API, there are lots of things you can do right, and plenty of pitfalls. Most of both of these are completely specific to the situation you are designing for but I have one tip that has helped me out in a number of scenarios: Include a version parameter with every method call.

This is invaluable, not just in development where you can increment when you change the API (which could be quite often!) but also in production. For example if you want to extend or alter an existing service, you can identify which version of the API the client thinks it is accessing and behave accordingly – either letting them know there’s a new version, or preserving previous behaviours. Its never ideal to change the API of an existing service but sometimes it makes more sense to do so, especially if its just to include an additional parameter or something else quite minor, but which does cause an API change.

When you publish your shiny new service which does everything you need (including the hoovering), it might seem a bit redundant to require a field which is always set to the string “1.0” … but in 18 months time, you’ll be patting yourself on the back.

Saving State in a Web Service

This is a mini series on points to consider when designing and building web services. So far there have been posts on error feedback for web services and auth mechanisms for web services.

Web services, by their very natures, are stateless, and this is no different to any other web application with a frontend. Its often helpful to keep track of the sequence of events something experiences. Similarly we might want to store the details a particular piece of data encounters on its lifetime in the system. When it was created, when it was changed, where in a given process it is up to, and so on.

A good example of this is a service I run for a few friends which accepts a URL, requests it and takes a screenshot, then turns that into a thumbnail and makes it available. There’s a few definite states in that sequence and its better to store which it is than try to guess from which fields have dates in or something. So the states are something like “new”, “error”, “in progress”, “ready” and “expired”. I can look at any of the jobs that come in, at any time, and know exactly where that item is up to.

When Things Go Wrong

It’s also pretty to have a strategy for failure. I already talked about giving users sensible feedback from a service, but the service also needs to keep track of what’s happening. There are decisions to make which depend entirely on the application under consideration but for example whether a failure is terminal, or whether the system should keep trying is quite an important thing to consider. Perhaps you just want to flag records that failed, so you can check on them later. Or you might want to retry – a set number of times? Or at decreasing intervals? An undesirable outcome would be to have the same record submitted every minute (or whatever) forever, so its worth planning to avoid this eventuality. Think also about the likely causes for failure – a split-second glitch or a likely human error which might take a day or two to be noticed and rectified?

Logging

Logging is something which is ideally of zero value. If nothing ever went wrong, you’d never care to look at an individual record and dig into its journey. However in the real world, we do need to be able to debug systems, sometimes under pressure. With logging there are a few different choices – whether to log to file or database, and whether to log continuously, or only at given times. Times when you might want to enable or increase logging are in development and when tracing a bug. However having some background amount of logging (and a way to stop the archives becoming too large) is recommended to keep track of who did what and when. Bear it in mind for a service just as you would for a web application.

Fixing Broken Serendipity Category

I migrated this blog to serendipity almost two years ago, and there have been a few things about it which have always driven me a bit mad. Many of these improved when I upgraded to version 1.4.1 of s9y but a few have persisted, including having two of my sidebar categories not display correctly. Where most of the categories behave as expected, two of of them just didn’t apply any filter at all and all my posts were visible on these pages.

I finally sat down today to diagnose the problem and discovered I was missing a record from the serendipity_permalinks table which was stopping s9y from being able to look up the id of the category. It was my craft category which is id 7 – all I had to do was run the following against mysql:

insert into serendipity_permalinks set permalink = "category/craft", entry_id=7, type="category";

So now my craft category works fine. If anyone knows how to stop my feeds from showing old articles as new when I edit them but don’t update the publication date, I’d be grateful! A bunch of imported posts are still missing their images, would be nice to be able to fix these without polluting my feed.

Updating Memcached on Ubuntu Jaunty

I’ve been working with memcache-related things lately and ran into a problem where the library I was using just didn’t seem to do what its documentation said it would. It turned out that it was making a “gets” call rather than a “get” call – and this functionality wasn’t introduced to memcached until version 1.2.4. Closer inspection shows that although Ubuntu Jaunty Jackalope (9.04) is only a few months old, and memcached 1.2.4 is about 18 months old, its not included and Ubuntu versions Hardy, Intrepid and Jaunty all had 1.2.2 version of memcached.

Credit to the Ubuntu people for resolving this issue already – since memcached 1.2.8 is currently pencilled in for Karmic Koala release of Ubuntu later this year – but I can’t wait that long so I updated my own memcached, it was pretty easy so here are the steps in case anyone else wants to do the same.

  1. download memcached from http://www.danga.com/memcached/download.bml
  2. check you have the dependencies you need. The only thing I didn’t have was the libraries for libevent, which you can install through aptitude with aptitude install libevent-dev
  3. compile as you usually would: configure/make/make install

The final step is to get memcached running – I actually did aptitude remove memcached to get rid of my old version and stop myself from being confused later. Then to start it from command line I used:

/usr/local/bin/memcached -m 64 -p 11211 -u nobody -l 0.0.0.0

The above worked for me and allowed me to use the functionality available in the newer library (specifically I was looking to use the cas (compare and swap) functionality in the new PHP memcached extension) – it probably works on other distros too but I didn’t test it, if it works for you or if you have anything to add then please leave a comment!