seeseekey.net - Invictus Deus Ex Machina

Der Titel dieses Artikels, könnte den Leser glauben lassen, das es in diesem Artikel um ein Skript geht, welches irgendwelche Vorteile bei schlechten Netzwerkverbindungen bringt. Allerdings ist das Gegenteil der Fall. Bei dem in Go geschriebenen Tool mit dem Namen Comcast handelt es sich um ein Skript zur Simulation eines schlechten Netzwerkes.

Comcast auf GitHub

Comcast soll dabei helfen Anwendungen zu testen, welche Netzwerkfunktionalitäten nutzen. So kann man überprüfen das die Anwendungen auch unter schlechten Bedingungen funktionieren (und falls dies nicht der Fall ist nacharbeiten). Das Skript läuft unter Linux, Mac OS X sowie BSD-Systemen. Der Quelltext der unter der Apache-Lizenz stehenden Software ist auf GitHub zu finden.

Microsoft kauft Mojang und damit Minecraft. Wenn man sich andere Akquisitionen von Microsoft im Spielebereich anschaut, bekommt man bei dieser Vorstellung ein mulmiges Gefühl. Entweder Sie fahren das Spiel gegen die Wand, oder es läuft demnächst nur noch auf Microsoft-Betriebssystemen. Natürlich kann auch alles funktionierten und unsere Befürchtungen erweisen sich als gegenstandslos. Allerdings zeigt der Aufkauf von Mojang eine Abhängigkeit auf. So haben viele Menschen riesige Bauwerke geschaffen, welche unter Umständen bald nicht mehr verfügbar sind. Minecraft ist nicht nur ein Spiel, es ist ein Kreativbetriebssystem. In einem solchem Fall spielt freie Software ihre Vorteile aus. Bei einer solchen Software, kann man das ganze einfach forken und in seinem Sinne weiterentwickeln. Bei proprietärer Software wird dies schwierig.

Eine von vielen Minecraft-Welten

Mit Minetest gibt es einen durch Minecraft inspirierten Clone, welcher für Mac OS X, Linux und Windows verfügbar ist. Das Spiel ist im Gegensatz zur aktuellen Minecraft-Version etwas rudimentär, was Dinge wie verfügbare Blöcke und ähnliches angeht. Allerdings relativiert sich das ganze wenn man sich die API-Schnittstelle anschaut. Mit Hilfe der API, kann man alle möglichen Erweiterungen wie Loren, TNT, Mobs oder Pyramiden ins Spiel holen. Die maximale Weltgröße ist auf −30912 zu 30927 in allen Dimensionen (auch Z) beschränkt. Etwas seltsam erscheint mir allerdings die Speicherung der Map in einer SQLite-Datenbank — dort muss sich zeigen ob dies bei großen Welten wirklich performant ist. Auch für Server-Backups ist dieses Verfahren nicht wirklich gut geeignet. Minetest ist in C++ entwickelt, was sich positiv auf die allgemeine Performance auswirkt, so das es auch auf schwächeren Rechnern genutzt werden kann — so gibt es schon Versuche das ganze auch auf dem Raspberry Pi zum laufen zu bringen.

Minetest in Aktion

Die Entwicklung von Minetest sieht dabei vielversprechend aus, so das man in Zukunft viele Verbesserungen und neue Features erwarten darf. Neben dem Client ist auch ein Server für den Mehrspieler-Betrieb verfügbar. Der unter der LGPL lizenzierte Quellcode kann über GitHub bezogen werden. Die offizielle Seite von Minetest ist unter minetest.net zu finden.

Wer in das Versionskontrollsystem Git einsteigen möchte, aber keine Lust hat ein Tutorial nach dem anderen durchzuprobieren, sollte es mal mit try.github.io versuchen. Dabei handelt es sich um ein von GitHub zur Verfügung gestelltes interaktives Tutorial in 25 Schritten.

try.github.io

Dabei wird man Stück für Stück in die Git Befehle eingeführt und kann das live am angezeigten Octobox Repository ausprobieren. Das ganze Tutorial sollte dabei in etwa 15 — 30 Minuten in Anspruch nehmen.

Möchte man einen Git Branch entfernen, so ist dies auf der Konsole mit einer Zeile erledigt:

git branch -D alterBranch

Unter TortoiseGit, einer freien Git Integration für Windows ist dies etwas komplizierter, da das ganze etwas versteckt ist. Um einen Branch zu löschen, öffnet man mittels des Kontextmenüs den Switch/Checkout-Dialog. Dort klickt man auf den Button mit den drei Punkten.

Switch/Checkout

Anschließend öffnet sich ein Dialog welcher eine Übersicht über alle Repository-Branches anzeigt. Dort kann der gewünscht Branch mittels Kontextmenü gelöscht werden.

Manchmal möchte man einen Remote-Tag unter Git wieder entfernen bzw. ihn komplett löschen. Dazu dienen folgende Kommandos:

git tag -d tagToBeRemoved
git push origin :refs/tags/tagToBeRemoved

Im ersten Schritt wird der Tag lokal entfernt. Anschließend wird die Änderung in das Remote-Repository übertragen. Damit ist der Tag Geschichte und sollte nicht mehr auftauchen.

Unter Git möchte man manchmal ein Verzeichnis von einem Repository zu einem anderen verschieben. Natürlich soll dabei die Revisionsgeschichte nicht verloren gehen. In diesem Fall hilft folgendes Bashskript:

#!/bin/sh
# moves a folder from one git repository to another
# moveFolder <absolute repository one path> <repository one folder> <absolute repository two path>

# prepare repository one
cd $1
git clean -f -d -x
git checkout -b tmpBranch
git filter-branch --subdirectory-filter $2 HEAD
mkdir $2
mv * $2
git add .
git commit -a -m "Move files into folder"

#import in repository two
cd $3
git remote add repositoryOne $1
git pull repositoryOne tmpBranch
git remote rm repositoryOne

#cleanup
cd $1
git checkout master
git branch -D tmpBranch

#remove folder with history from repository one
cd $1
git filter-branch -f --index-filter "git rm -rf --cached --ignore-unmatch $2" HEAD

Genutzt wird das Skript dabei wie folgt:

./moveFolder /absolute/path/to/repo/one folderFromRepoOne /absolute/path/to/repo/two

Nachdem das Verzeichnis in das neue Repository mitsamt der Revisionsgeschichte übertragen wurde, wird es aus dem alten Repository entfernt. Das Skript funktioniert dabei unter Windows, Linux und Mac OS X. Die jeweils aktuellste Version ist auf GitHub zu finden.

Nachdem ich versuchte Git per WebDAV in Verbindung mit ownCloud einzurichten, fiel mir ein, das die größeren Paketen (ab Premium) bei all-inkl.com auch einen SSH Zugang beinhalten. Mit diesem ist es relativ einfach das Webhosting Paket als Server für Git Repositories zu benutzen. Sollte auf dem lokalen Rechner noch kein SSH-Schlüssel erzeugt worden sein, so kann dies mittels:

ssh-keygen -t rsa -C "seeseekey@example.org"

nachgeholt werden. Nun kann der Schlüssel an den all-inkl Server übertragen werden:

ssh-copy-id -i ~/.ssh/id_rsa.pub ssh-nutzername@example.org

Anschließend ist es möglich sich mit dem all-inkl SSH Server ohne Authentifikation über ein Passwort anzumelden:

ssh ssh-nutzername@example.org

Dort legen wir in dem Ordner in welchem unserer Git Repository landen soll ein leeres Repository an:

git init --bare

Als nächsten Schritt trägt man einen Remote an ein lokales Git Repository an:

git remote add origin ssh://ssh-nutzername@example.org/www/htdocs/nutzername/repos/Example.git

Danach kann das lokale Repository mit dem Befehl:

git push origin master

auf den entfernten Server kopiert werden. Benötigt man es auf einem anderen Rechner so kann das ganze mittels:

git clone ssh://ssh-nutzername@example.org/www/htdocs/nutzername/repos/Example.git

bewerkstelligt werden.

Beim Versuch ein lokales SVN Repository mittels:

git svn clone --stdlayout svnrepo gitrepo

in ein Git Repository zu klonen, kam es zu folgender Fehlermeldung:

E: 'trunk' is not a complete URL and a separate URL is not specified

Die Lösung liegt hier an der richtigen Syntax des Pfades, so das es mit

git svn clone --stdlayout file:///home/seeseekey/svnrepo/ gitrepo

funktioniert.

Heute erscheint die neue Ausgabe (7.13) des Magazins „Windows Developer“. Der Themenschwerpunkt der Ausgabe liegt dabei auf dem Thema Git in Verbindung mit dem Visual Studio und Windows.

Die aktuelle Ausgabe von Windows Developer

Passend dazu gibt es von mir in dieser Ausgabe den 6-seitigen Artikel „Git Backstage“ welcher sich mit den physikalischen und logischen Speicherstrukturen und –mechanismen eines Git Repositories beschäftigt. Windows Developer kann dabei für 9,80 € am Kiosk bezogen werden.

Einer der Vorteile von Git ist die große Freiheit welche einem das System gibt. Einer der Nachteile widerum ist die große Freiheit welche Git bietet. Deshalb sollte man sich für die Entwicklung in einem Git Repository einen Workflow zurechtlegen. Hier sei ein exemplarischer Workflow vorgestellt.

Der Git Standardbranch trägt den Namen „master“. In diesem Branch wird per Definition nichts entwickelt. Soll nun ein Feature implementiert oder ein Bug behoben werden, so wird dafür ein Branch eröffnet. Wenn das Feature im Branch implementiert und getestet ist, so kann es wieder in den „master“-Branch gemergt werden. Branches welche gemergt wurden und nicht mehr benötigt werden können dabei wieder entfernt werden. Das gleiche gilt für alte Tagbranches.

Der Vorteil der sich aus dieser Vorgehensweise ergibt, ist das der „master“ immer relativ stabil bleibt, da nur getestete Änderungen in ihn wandern. Außerdem kann man so mehrere Features parallel entwickeln. Bei der Benennung könnte man sich z.B. an folgendes Schema halten:

Featurebranch: feature-supportTiff
Bugfixbranch: bugfix-invalidFormatHandler
Tagbranch: tag-13.04

Interessant wird es wenn ein Release einer Software ansteht. Hier sollte man von der entsprechenden Software welche in einem Git Repository liegt einen Branch erstellen und diesen entsprechend benennen: z.B. als „tag-13.04″. In diesem Branch wird die Software auf Herz und Nieren getestet und auftretende Fehler behoben. Neue Features werden dabei nicht mehr entwickelt.

Wenn nun ein Fehler auftritt hat man drei Möglichkeiten damit umzugehen. Wenn der Fehler nur in dem Tagbranch auftaucht, wird er dort behoben, indem ein Bugfixbranch erzeugt wird, der Fehler behoben und der Bugfix getestet wird. Anschließend wird er wieder in den Tagbranch gemergt.

Ist der Fehler im „master“-Branch und im Tagbranch des aktuelles Releases enthalten, so wird ein Bugfixbranch vom „master“-Branch erstellt, der Fehler dort behoben und anschließend in den „master“ und in den Tagbranch zurückgemergt.

Dies funktioniert natürlich nur, wenn sich der „master“ und der Tagbranch nicht zu weit auseinander entwickelt haben. Ist der Fehler noch in beiden Branches vorhanden, die Unterschiede zwischen den selbigen aber zu gravierend, muss für jeden der beiden Branches ein Bugfixbranch erstellt werden und der Fehler in diesen Branches separat behoben werden. Anschließend wird das ganze in die entsprechenden Branches zurückgemergt.

Wenn alle gefundenen Fehler im Tagbranch behoben wurden bekommt der entsprechende Commit einen Tag in der Form „13.04″. Sollten später weitere Fehler beseitigt werden so werden diese im entsprechenden Tagbranch behoben und anschließend ein neuer Tag vergeben (z.B. „13.04.1″), welches das Bugfixrelease kennzeichnet.

Das ist natürlich nur ein Vorschlag für einen Workflow, der den eigenen Anforderungen unter Umständen angepasst werden muss. So könnte man für sich entscheiden das kleinere Fehler direkt im „master“-Branch behoben werden. Das liegt dann aber in der Verantwortung des Nutzers, der nach diesem Workflow arbeitet.