It looks like these days are some of things breaking and the being fixed in rapid succession. After the MacBook’s case breaking and being repaired soon after last week, I could finally pay attention to more pressing matters.
Last week our washing machine stopped working. We only bought it after our previous washing machine broke last year, so this was a bit of a bummer. It’s a rather cheap washing machine and for some reason it was bought about 30km away – i.e. too far to return it to the dealer who should give you – or arrange for you with the manufacturer – some kind of warranty. Double bummer.
Now washing machines aren’t iPods. Sturdy mechanics work in there. So it’s a bit of a mystery what should actually break. Just some lights on the control panel were flickering wildly. After consulting the manual which is in German – or rather the result of a poor translation attempt to German we learned that this flickering meant that the door doesn’t close properly. And in the typically ‘helpful’ FAQ style they recommended closing the machine’s door to fix the problem. Haha, we had a laugh.
My guess was that the switch which is used to figure out whether the door is closed must be broken. Either mechanically or electrically. And my ideas for fixing that reached from re-wiring the switch to see the door as always closed to buying a new switch. To see what we can do, we disassembled the machine which was surprisingly easy. I was quite impressed how clean the machine looked inside with all wires even having nice connectors rather than just being soldered on (perhaps there’s some law about that?). We found the switch which I suspected to be the culprit but it looked as good as new. And I had it checked later on which taught us it is working.
Uh-Oh. The next fear was that something in the machine’s electronics was screwed up. Which would mean that probably the mechanical repair people couldn’t help either and we’d absolutely need to deal with the warranty stuff. Hence we studied the manual again to figure out how that will work. And between all the broken sentences discovered one that suggested the machine can actually be re-set.
And after re-assembling it, we did just that. Held the Start button for five seconds and it worked. Just like an iPod after all.
I guess this highlights how important it is to have good documentation. That is, documentation which is actually readable and which isn’t so bad or inaccessible that you don’t expect anything helpful in there to begin with.
Everybody says you should use versioning systems. For programming and possibly for other files you edit over a long time as well. I never did that. Not because I think versioning is a bad idea – it certainly appeals to my obsessive-compulsive side. But it just seems to be an annoying thing. Not the usage per se. But the setup. While installing the tools isn’t too bad thanks to Martin Ott’s installer package, actually starting to use it is. You’ll need to read more than a paragraph of documentation, you’ll need to think about a good strategy for what you are doing. And you’ll have to actually do it.
Which I did a few weeks ago. And it seemed like a good idea. Until today: when I had changed a file in my project but couldn’t commit those changes anymore. I tried many things. And while many of them seemed to foul up the situation even more, none of them let me change, update, move, rename or even delete the file.
If I understood things correctly, the problem was that the file in question was a nib file which – technically – is a folder. And that Subversion does its best to litter all your folders with invisible subfolders containing all the versioning stuff. And with that the time tested strategy of deleting that nib file which you just screwed up and replacing it with an older copy ends up being a bad idea. As your backup copy may not have any or the correct invisible files inside it.
I couldn’t get that to work again and had to create a new repository where I uploaded, and then again downloaded all my files before I could continue working. All that seemed a bit idiotic as the whole point of the Subversion exercise was to not just make a new backup copy every now and again but to keep the whole stream of the files’ history accessible.
Feel free to point me to a magic command which resolves such situations. And any hints why exactly there should be a need to reset a washing machine are appreciated as well.
Unlike TextEdit (and more generally Cocoa’s text system) with .rtfd files Interface Builder should preserve the .svn directory. The problem is, more or less, that you’re not using Subversion the way you should; actually using older revisions is the replacement for your “time tested strategy” of keeping around backups. If you want to go back to an older version, then use svn up with an older revision number, date, or svn switch to a tag/branch; get what you want, then switch back to the head revision.
In the case of rtfd bundles you may find my script ‘fixsvn’ useful - it restores .svn directories in case they have been accidentally obliterated. I wrote it back in 2003 but it still works.
The email I sent with the script is at: http://svn.haxx.se/dev/archive-2003-02/1321.shtml
When I searched for the script online, I also found a copy in Growl’s Subversion repository:
Or you could switch to another version control system. :-) Some, like Mercurial which I’ve been using a lot recently, only put metadata at the root of a repository. (In distributed systems there is typically no difference between a repository and working copy in Subversion’s terms.) So you can move files around inside there to your heart’s content.
Thanks for the script Nicholas, I’ll keep it handy for the next time I use things in the ‘wrong’ way.
I guess my main problem here is that Subversion just started ignoring me because of this problem and refused to do anything with the file. Thanks to those missing files I couldn’t even successfully rename or delete them. I have come to expect more hand-holding in such situations. With a warning that something went wrong and a hint how to fix it (or even an offer to fix it for me).
While that Mercurial thing sounds interesting, just getting it to work would probably require more work than double clicking an installer. So it’s probably not for me. I am not that interested in the intricacies of versioning systems. I’m happy to just select files and click the Commit menu item in XCode… (am I right to think that there’s no way to commit the project file itself from within XCode?)
Also, is the nib file the equivalent of an executable? I use svn to only keep track of my source files, and build fresh executables after each checkout… svn probably isn’t so great for keeping track binaries - can you imagine diff-ing those?
I think technically a nib file is an archive for objects. The name shows off their history and is supposed to be an acronym for NeXT Interface Builder. (Just as Cocoa class names have the somewhat unfortunate NS prefix as they come from NeXT Step.)
In practice they are used to store the windows and menus of applications in them. Using Interface Builder that gives you simple editing and localisation of your GUI. As well as hooking up many things like the methods called my menus or buttons, number formats or data bindings. Just look inside the English.lproj folder in any Cocoa application and you’ll almost certainly find some of those.
I think the files are mostly binary and as I only edit them via Interface Builder, I am not even sure a diff would be all that helpful. But having convenient access to the different versions of the files can still come handy. I also like to have all of my source files in the archive.
Received data seems to be invalid. The wanted file does probably not exist or the guys at last.fm changed something.