\documentclass[11pt,a4paper]{article}
% save as utf-8-emacs-unix
% language support
\usepackage[german]{babel}
%\usepackage{german}
\usepackage[utf8]{inputenc} % can use Umlauts now ü instead of "u
\usepackage{url} % \url{} \path{} with correct "hyphenation"
\parindent=0pt
\begin{document}
\title{Fossil --- Quellcodearcheologie}
\shorttitle{Fossil --- Quellcodearcheologie}
\author{Carsten Strotmann}
\maketitle
\begin{abstract}\itshape
Bei jedem langlebigen Softwareprojekt kommt irgendwann der Zeitpunkt, an dem der Entwickler in die Vergangenheit reisen möchte, um im Quellcode der Vergangenheit
auf die Suche zu gehen: nach Fehlern, die sich unerkannt eingeschlichen haben; nach Funktionen, die in der Vergangenheit noch funktionierten oder nach dem
einfachen Algorithmus, der doch viel besser war als der neue, clevere. In diesem Zeitpunkt freut sich der Entwickler, welcher den Quellcode seit Anbeginn in einer
Softwareversionsverwaltung hat ... wenn er diese denn hat ...
\end{abstract}
\begin{figure*}[b]
\begin{center}
\includegraphics[width=\textwidth]{2012-01/fossil1}
\caption{\label{fossil1}Die \emph{Timeline}--Ansicht in der Fossil--Web--Oberfläche}
\end{center}
\end{figure*}
\begin{figure*}[t]
\begin{center}
\includegraphics[width=\textwidth]{2012-01/fossil2}
\caption{\label{fossil2}Die Detail--Ansicht für ein \emph{Artifact} in der Fossil--Web--Oberfläche}
\end{center}
\end{figure*}
\begin{multicols}{2}
% --------------------------------------------------------------------
\section{Softwareversionsverwaltung}
\label{sec:intro}
Auch der unorganisierteste Entwickler betreibt `Ad--Hoc'--Versionsverwaltung. Diese `Ad--Hoc'--Versionsverwaltung hat viele Gesichter, und wir alle habe diese
schon selbst benutzt: Die mit Datumsstempel versehene Kopie des Quellcode-Verzeichnisses, die ZIP--Datei, die mehr oder weniger regelmäßig auch als Datensicherung
erstellt wird: {\small\texttt{software-v2-20120220.zip}}.
`Ad--Hoc'--Versionsverwaltung ist nicht optimal, die Suche nach Änderungen und auch der Vergleich von Versionen ist manuell und mühsam.
Kommerzielle-- und auch Open--Source--Versionsverwaltungssysteme wie CVS, SVN, git oder Mercurial bieten eine ganze Reihe von Funktionen,
sind aber umfangreiche Programmpakete, in die sich der Entwickler erst einarbeiten muss. Zusätzlich werden noch Webserver benötigt, eine spezielle Scriptsprache
ist Bedingung für die Installation, und schnell ist ein Tag vergangen. Zu viel Aufwand für den Forth--Entwickler, er will ja schließlich die kostbare Zeit
benutzen, um Forth zu schreiben, nicht um Softwareversionsverwaltung zu lernen.
\section{Fossil}
\label{sec:Fossil}
Die Software--Versionsverwaltungssoftware Fossil [1]
% \footnote{\url{http://fossil-scm.org}}
hebt sich wohltuend von den übrigen
SCM\footnote{Source--Code--Management}--Werkzeugen ab und ist ganz im Forth-Sinne klein und effizient. Das fängt schon damit an, dass die Fossil--Installation
eine einzelne ausführbare Binärdatei ist (fossil.exe unter Windows, fossil unter Unix/MacOS). Keine Installations-Prozedur erforderlich, sondern das Programm wird
einfach an die Stelle auf der Festplatte kopiert, wo man sie denn haben möchte, und fertig. Die Fossil--Webseite bietet ausführbare Dateien für Linux, MacOS X und
Windows, und den Quellcode zum Download an. Zum Betrieb von Fossil wird keine weitere Software benötigt, kein Webserver, keine Scriptsprache muss installiert sein,
nur die Fossil--Programmdatei genügt.
\section{Erste Schritte}
\label{sec:erste Schritte}
Alle Quellcode--Dateien und die Änderungen an diesen Dateien, sowie alle anderen Metadaten, die Fossil speichert, werden pro Projekt in einer einzigen
Datei gehalten, dem Projekt--Repository. Technisch gesehen ist das Projekt--Repository eine SQLite--Datenbank, aber dieser technische Hintergrund ist für die
Benutzung von Fossil unwichtig.
Wenn wir ein neues Softwareprojekt unter Quellcodeverwaltung nehmen wollen, so müssen wir erst eine Repository--Datei erstellen. Die Repository--Datei kann in
einem beliebigen Verzeichnis stehen, und kann auch später ohne Probleme umherkopiert oder auf einen anderen Rechner übertragen werden.
Ein Repository wird erstellt mit {\small\texttt{fossil new <projektname>}}. Nicht nur Quelltexte für Programmiersprachen können mit SCM--Systemen verwaltet werden,
sondern auch Texte für die VD. Für diesen Artikel habe ich ein Repository namens `vd-201201-fossil' angelegt:
\newpage
\begin{footnotesize}
\begin{verbatim}
# fossil new vd-201201-fossil
project-id: 071e05233e84654cc573cf79f6df21ebb05a24fa
server-id: 1dd3462892e01ecbaf62abd48de714d394328bb4
admin-user: cas (initial password is "abf70a")
\end{verbatim}
\end{footnotesize}
Um mit einem Repository arbeiten zu können, müssen wir dieses öffnen:
\begin{footnotesize}
\begin{verbatim}
# fossil open vd-201201-fossil
\end{verbatim}
\end{footnotesize}
Der Befehl `fossil info' gibt uns Informationen über das gerade geöffnete Repository:
\begin{footnotesize}
\begin{verbatim}
# fossil info
project-name: <unnamed>
repository: /home/cas/Documents/vd-201201-fossil
local-root: /home/cas/Documents/
project-code: 071e05233e84654cc573cf79f6df21ebb05a24fa
checkout: efc57e6bf2a94a74096cbd27a7860e2dae21bb24
2012-02-22 02:30:22 UTC
tags: trunk
comment: initial empty check-in (user: cas)
\end{verbatim}
\end{footnotesize}
Zum Anfang ist das Repository noch leer, wir müssen die Dateien hinzufügen, die wir gerne in der Quellcodeverwaltung haben möchten. Hierzu dient der
Fossil--Befehl
`add'. Mit `add' können einzelne Dateien, aber auch ganze Dateibäume hinzugefügt werden. Wird dem `add'--Befehl ein Verzeichnis gegeben, so wird dieses Verzeichnis
inklusive aller Unterverzeichnisse unter die Quellcodeverwaltung gestellt. In Falle des VD--Artikels ist es nur eine Datei:
\begin{footnotesize}
\begin{verbatim}
# fossil add fossil.tex
ADDED fossil.tex
\end{verbatim}
\end{footnotesize}
Die Datei `fossil.tex' ist nun unter der Versionkontrolle, aber noch nicht in der Repository--Datenbank gespeichert. Erst wenn wir die Datei per `commit'
das erste Mal in das Fossil--System übernehmen, wird die Datei in das Repository gespeichert:
\begin{footnotesize}
\begin{verbatim}
# fossil commit -m "Erste Version des fossil-Artikels"
New_Version: caf95931d089baaaef35cc70783613712da21c1b
\end{verbatim}
\end{footnotesize}
Jede Änderung an einem Repository bekommt eine eindeutige kryptografische Checksumme, diese wird als Versionsnummer ausgegeben. Mit der Option `-m' wird ein
Kommentar zu dieser Änderung angegeben. Wird `-m' weggelassen, so fragt Fossil nach einem Kommentar auf der Kommandozeile.
Nach ein paar Änderungen im Quellcode erfolgt ein weiterer Commit:
\begin{footnotesize}
\begin{verbatim}
# fossil commit -m "Zweiter Commit"
New_Version: df0007f5e7259144b73dd98497d419a7f63f22b7
\end{verbatim}
\end{footnotesize}
Somit haben wir nun zwei Versionen des Artikels in der Datenbank. Der Befehl `timeline' gibt eine Übersicht der Änderungshistorie mit den Kommentaren:
\begin{footnotesize}
\begin{verbatim}
# fossil timeline
=== 2012-02-22 ===
02:48:05 [df0007f5e7] *CURRENT* Zweiter Commit
(user: cas tags: trunk)
02:41:46 [caf95931d0] Erste Version des fossil-Artikels
(user: cas tags: trunk)
02:30:22 [efc57e6bf2] initial empty check-in
(user: cas tags: trunk)
\end{verbatim}
\end{footnotesize}
Der Befehl `diff' gibt die Änderungen zwischen den Versionen im Repository aus. Mit `fossil help diff' bekommt man die Hilfe zum `diff'--Befehl angezeigt. Mit dem
Befehl `revert' kann zu einem früheren Zeitpunkt in der Quellcode--Historie zurückgekehrt werden.
Es ist gefahrlos möglich, ein Repository geöffnet zu halten, auch wenn der Rechner neu gestartet wird. Nur wenn das Repository verschoben oder auf einen
anderen Rechner kopiert werden soll, sollte das Repository vorher mit `fossil close' geschlossen werden. Vor einem `close' erst noch alle Änderungen
an den Quelldateien per `commit' in die Datenbank übernehmen. Der Befehl `help' gibt eine Liste aller Fossil--Befehle aus, und `fossil help <Befehl>' gibt
eine Beschreibung des Befehls aus.
\section{Fossil Web-Oberfläche}
\label{sec:Fossil Web-Oberfläche}
Neben der Kommandozeilenschnittstelle bietet Fossil auch eine Web--Oberfläche auf Port 8080 der Loopback--Adresse. Dieser Webserver wird mit `fossil server'
gestartet. Im Web--Browser unter der URL http://localhost:8080/ befindet sich dann die Konfigurationsoberfläche für Fossil. Neben dem Projektnamen können über diese
Oberfläche die Sicherheitseinstellungen für das Repository vorgenommen werden (wenn Fossil als Webserver über das Internet betrieben wird), und die
Web--Oberfläche enthält auch ein Bug--Tracking--System um Fehler--Reports zu verwalten, sowie ein einfaches Wiki--System, welches zur Dokumentation des Projektes
verwendet werden kann.
Fossil zeigt, dass auch mächtige Quellcode--Verwaltungssysteme nicht kompliziert zu installieren und bedienen sein müssen. Ein Fossil--Repository ist in wenigen
Minuten erzeugt, Zeit, die später hundertfach durch die Funktionen des Systems wieder eingespart werden kann. Mit Fossil gibt es keine Ausreden mehr,
Software--Versionsverwaltung sollte für jedes Projekt eingesetzt werden.
\end{multicols}
\section*{Links}
[1] \url{www.fossil-scm.org} Fossil Homepage
\vfill
%Bild: Gondwana_fossil_map_ger.png
\begin{figure*}[h]
\begin{center}
\includegraphics[width=1.0\textwidth]{2012-01/Gondwana_fossil_map_ger}
\caption{\label{bild1}Lage der Fossilien, daher Rückschluss auf Gondwana\newline
Quelle: \url{http://commons.wikimedia.org/wiki/File:Gondwana_fossil_map_ger.png}}
\end{center}
\end{figure*}
\vfill
\end{document}