Spent most of today fiddling with SVN in OSX, as I’m still suffering with this damned cold and can’t do anything more exciting. One-line reviews of the SVN clients I’ve tried:
svnX Confusing GUI, rather slow.
ZigVersion Surprisingly intuitive GUI, but no mention of the fact that it’s shareware until you run it.
XCode Buggy and lacking in features; documentation does not reflect the capabilities of the client (it insists that you can’t checkout code when you quite blatantly can, for example).
SCPlugin Buggy when used with Leopard, but features TortoiseSVN-style integration with the Finder.
None of them comes remotely close to offering the functionality of TortoiseSVN, which is a shame. It also highlights what a good job the Tortoise guys have done. I’ve decided to go for SCPlugin, but I’m keeping the others installed in case I need a repo browser.
Managed to get in a few Woopsi changes, despite not being able to think straight yet. I’ve removed the TextViewer class, because pretty much everything it did can now be done by the MultiLineTextBox much more cleanly. This does impose some considerable limits - the TextViewer could scroll through the number of rows of pixels represented by an s32, whilst the MultiLineTextBox can only scroll through an s16. However, that’s still over 3,000 lines of text when using the default 8x10 system font; any more than that and you should really consider breaking the text into multiple files anyway. The demo now uses a MultiLineTextBox for its large text display, and it finally clips properly.
Fixed a few more bugs in the Text and MultiLineTextBox classes; they were mainly fiddly problems with overflows or signed/unsigned wraparounds. Easy to spot when you can step through with a debugger.
The XCode project is now in the SVN repository. As long as you’ve got SDL installed (from libsdl.org) you should just be able to hit “Build and Go” and have it running.
There are a couple of things to watch out for in the SDL code. The first one is that, in order to prevent the creation of unkillable processes, I’ve hacked a check for the “Esc” key into the main loop. This means that the SDL code gets checked in two places - inside the Woopsi class and in the main.cpp file. Unfortunately, this means that an event may be picked up by the “wrong” event processor and therefore won’t be passed to the “right” processor. This usually exhibits itself as mouse button releases that don’t get registered. I’ll have to see if there’s a tidier way of handling this that won’t interfere with the DS version of the code.
The second thing to watch out for is the SDL licence. Unlike Woopsi, SDL is licenced under the LGPL. This means that, if you compile Woopsi and statically link the SDL library with your code and then distribute that binary, your project will also be under the LGPL. Although Woopsi is distributed under the very permissive BSD licence, the less permissive LGPL will take precedence if you statically link with an LGPL library. If you intend to distribute SDL-enabled binaries, you should dynamically link SDL with your project, which will mean that you can distribute it under whatever licence you like (whilst remembering to adhere to the terms of Woopsi’s BSD licence).
I can’t imagine why anyone would want to distribute SDL builds of Woopsi - it’s only function is as a test environment - but it’s worth keeping in mind.