Smallsource: A bridge between Monticello and “normal” versioning systems

Today is Monticello day here at Joachims Small World, and while we’re at it, let’s just take note of Dale’s work on connecting the Smalltalk world to version control systems the rest of the world is using, like Git, Subversion etc.

The image-based development approach in Smalltalk is one of the most scary differences to “normal programming” that people see. It somehow makes developers nervous to not see the files behind their code. In fact, for most developers on the planet, a program is made up of files much more than of code. Even if IDEs like Eclipse pretty much behave like an image-based system (subtracted the storage of instantiated objects, mostly), the whole process is centered around files.

Dale Henrichs of vmware is working on Smallsource, a system which tries to bridge the gap between git, svn and others and our way of thinking in objects. The first step is to tear classes apart into a tree of files, each representing the class definition or instance or class method. This tree can then be checked in and out of classical version control systems while still providing a way of comparing and merging on a method level rather than while classes. It sounds like a good idea and once the machinery of checking in/out and using the vcs’s diff/merge tools to maintain Smalltalk code could help us be more accessible to other communities. And we could maybe one day give up our proprietary version control systems and concentrate on other things (being an envy fanboy, I can hardly believe it was me who typed this).

Found via Torsten’s Blog

Schneeleoparden sind lausige Samba-Tänzer

Über die Feiertage war es Zeit, die IcyBox abzulösen und die Daten vom NAS auf den neuen Server zu übertragen. Die Einrichtung von OpenSUSE 11.2 von der c’t-CD war schmerzlos, und auch SAMBA einzurichten, war keine große Sache (allerdings ist das SUSE-Tool YAST für SAMBA eher ein Hindernis als eine Hilfe, die Datei /etc/samba/smb.conf zu editieren funktioniert deutlich besser!). Naja, lange Geschichte in Kurzform: der Linux-Server mit einem RAID1 stand in wenigen Stunden, inklusive SAMBA, Postgres, subversion etc.

Dann aber kam die große Zitterpartie: Die Daten mussten vom alten auf den neuen Server übertragen werden. Eigentlich keine große Sache, sollte man meinen: einfach die Dateien rüberkopieren, und fertig.

Nicht so mit Snow Leopard.

Ich wollte mir das Leben erleichtern, und den Mac und Chronosync benutzen, um ein einfaches Backup vom alten auf den neuen Server zu machen und möglichst keine Probleme mit Packages wie Keynote-Files etc. bekommen.

Leider war das aber nicht erfolgreich: massenhaft Fehler im Protokoll, leere Packages auf dem neuen Laufwerk und sonstige Horrorszenarien. Auch der Finder konnte nur die Ordner der obersten Ebene anlegen, fing dann an, die Dateien im ersten Ordner zu kopieren, und beim ersten Unterordner meldete der Finder, dass der Ornder bereits existiere und die Aktion abgebrochen werden müsse.

Zur Probe mal zunächst auf ein lokales Verzechnis am Mac kopieren funktionierte einwandfrei, sowohl per Finder als auch mit Chronosync. Aber egal, ob die lokale Kopie oder das Original übertragen werden sollte, es trat immer derselbe Fehler auf.

Mein erster Gedanke: meine Samba-Konfiguration am Server ist falsch. Also die dicke Schwarte aus dem Schrank geholt und Optionen gesucht, die verantwortlich sein könnten. Inherit-ACLs vielleicht? Oder force directory mode?

Pustekuchen. Snow Leopard hat einen Bug, der mich ein paar graue Haare und einige Stunden Zeit gekostet hat. Leider habe ich erst von diesem Bug gelesen, als ich ihn selbst gefunden hatte.

Irgendwie kam mir das schon sehr seltsam vor: auf den Mac kopieren ging problemlos, mit dem Finder und Chronosync aber nicht. Interessanter Weise konnten aber die Anwendungen, mit denen die fehlerhaften Packages (also Verzeichnisse, die nicht als solche angezegt werden, etwa Keynote-Präsentationen .key oder iCalamus-Dokumente *-icdk), die Daten problemlos auf dem neuen Server speichern. Leider ist es nicht wirklich erquicklich, einige hundert Präsentationen manuell mit Keynote aufzurufen und auf dem Server abzuspeichern.

Meistens kommen die richtigen Ideen ja unter der Dusche oder direkt vorm Einschlafen. Im letzteren Fall verhindern sie manchmal auch eben selbiges. So war’s in diesem Falle auch. Probier’s doch mal mit nem Mac mit Leopard anstatt Snow Leopard.

Und so kam es, dass die ganze Kopiererei eigentlich in einer knappen Stunde hätte erledigt sein können, wenn Apple nicht einen ziemlich üblen Fehler in seinem neuesten Betriebssystem hätte. Es lief durch wie geölt, keinerlei Probleme oder Fehler, und die Packages lassen sich auch vom neuen Server wieder öffnen und weiterbearbeiten.

Aber wieso sollten Apple-Updates besser sein als alle anderen…?

[UPDATE] Zwar hat Apple das Problem bisher nicht behoben, aber Econ Technologies bietet mit Version 4.05 von Chronosync einen Workaround für das Problem an:

• Implemented workarounds to numerous “Parameter Errors” some Snow Leopard users encounter when connecting to a server via SMB.

Lieber ein Ende mit Schrecken…

…als ein NAS-Gerät, das ständig zickt.
Monatelang waren wir mit der IcyBox IB NAS 4220 B ganz zufrieden. Es ist ein leises und sparsames Gerät, das seinen Job als NAS ganz gut macht, wenn man die richtigen Platten drin hat.
Ganz offenbar mag es keine Samsung-Platten und mit Western Digital gibt’s auch immer wieder Probleme. In unserem stecken zwei WD Platten (5000ABYS, um genau zu sein).
Seit aber vor kurzem das RAID aus den Fugen geraten ist (oder es schon länger aus den Fugen war, und es erst vor kurzem auffiel), und man dem Web Interface wohl nicht so recht trauen kann, macht mir das Ding echte Sorgen.

Als dann am Samstag aus heiterem Himmel angeblich eine Platte defekt war, und das RAID wieder hergestellt wurde, und nun angebliche wieder alles in bester Ordnung ist, die Kiste aber nicht immer hochfährt, ist für mich eines klar: keine Projekt- und Kundendaten mehr drauf.

Für diesen Job habe ich mir nun eine fast genauso sparsame und fast genauso kostengünstige Alternative ausgesucht, die hoffentlich noch vor Weihnachten ankommt.
Mit seinem Atom 330 und einem stinknormalen Linux (glücklicherweise habe ich genug Linux-Erfahrung) drauf, löst das Ding dann auch noch ein paar weitere Probleme:

• Es kann problemlos als Subversion-Server fungieren
• Es kann PostgresQL-Datenbanken verwalten (es werden maximal eine handvoll clients gleichzeitig drauf arbeiten)
• Wir können den Envy-Library-Manager drauf installieren
• Mit Webmin lässt sich auch hier eine hübsche Überwachungsoberfläche per Browser nutzen (um etwa den Status des RAIDs zu prüfen)

Es ist eben ein normaler Linux-Server mit fast genauso sparsamem Verbrauch wie die IcyBox, aber eben ein vollwertiger Rechner, an den man auch eine Tastatur und einen Monitor anstöpseln kann, wenn mal nichts mehr per SSH geht.

Bisher scheint mir der Anbieter auch sehr kompetent und freundlich.

Die von mir zusammengestellte Konfiguration wurde hinterfragt und ich habe heute gleich morgens einen Rückruf bekommen, um die offenen Punkte zu klären. Obwohl es sich hier um ein absolutes Low-Price-Modell aus der Produktpalette handelt. So kam nebenbei noch heraus, dass der im Webshop obligatorische RAID-Controller nicht wirklich dabei sein muss (ich will ein SoftRAID einrichten, um die Platten auch an Fremdmaschinen nutzen zu können, wenn mal gar nichts mehr geht). Und es werden keine separaten Festplatteneinschübe benötigt, weil die Platten in welchen verbaut werden. So ist meine Bestellung also um 300 Euro günstiger geworden.

Also bisher ein gutes Gefühl bei der Sache, aber noch habe ich die Maschine ja nicht…

Update: SVN on our IcyBox NAS 4220

Some moons ago I was looking for options to install SVN on our IcyBox. In fact after some searching I found a compiled binary .

I installed it and am we’re able to check in and out, but one thing I didn’t have/take the time to is to make it start on boot of the NAS. We do switch it off daily, because we suffer from a spindown problem that’s not really solved yet (The drives start up after a certain amount of time even if no client wants to access the shares), so this means we have to connect to the NAS via ssh and start svn manually if we need to access a repo.

I have found some descriptions on how to start processes at boot time in the NAS and I remember it looked like a bit of editing some files here and there and nothing really rocket science-like, but I still don’t have enough pressure to simply do it.

So to make it short: we do run SVN on the box, but we didn’t daemonize it yet. Maybe some time in autumn when the days are getting shorter