Beim IN-Berlin kann man auch verschiedene Versionskontrollsysteme hosten. Bisher haben wir Fossil, git, CVS, SVN, Hg und bzr, können aber auch neue nachinstallieren. Allerdings ist von denen nur Fossil automatisiert und mit eigener Userverwaltung benutzbar. Für das Anlegen/Löschen eines anderen Repositories und zugehöriger Benutzer muss man den Support kontaktieren.

Fossil

Fossil ist ein verteiltes Versionskontrollsystem, Wiki und Ticketsystem. Beim IN-Berlin kann man sich über das Service-Interface Fossil-Instanzen anlegen.

Ein brauchbares Cheat Sheet für Fossil findet man hier.

Anlegen eines Repositories

Ein Repository kann man sich im Service-Interface unter dem Punkt Fossil-Repository anlegen anlegen lassen, bzw. unter Fossil-Repository löschen hat man die Auswahl, angelegte Repositories zu löschen.

Einstellungen

Das Repository wird mit sitename_repositoryname bezeichnet und ist danach unter https://vcs.in-berlin.de/sitename_repositoryname erreichbar.

Ändern des Passworts

Das Passwort kann man nicht über das Service-Interface ändern. Wenn man sein Passwort vergessen hat, muss man den Support kontaktieren und dann wird das Passwort zurückgesetzt.

Wenn man noch Zugriff hat, dann kann man das Passwort über das Webinterface ändern, indem man sich mit dem gesetzten Passwort als Admin anmeldet, dann auf “Admin” geht, auf “Users” und dann auf den Adminuser (Standard ist “admin”). Dort kann man das neue Passwort setzen. Achtung: Es wird nicht nochmal bestätigt und ist sofort geändert!

Begriffe

Diese Begriffe werden im folgenden verwendet, sind aber nicht unbedingt nötig zur Verwendung von Fossil als Wiki oder Ticketsystem.

  • Versionskontrollsystem – ein System, mit dem man Dateien in unterschiedlichen Versionen verwalten kann.
  • Ticketsystem – mit einem Ticketsystem kann man einzelne Aufgaben (Tickets) erstellen und verwalten. Es eignet sich gut zur Arbeitsverwaltung in Gruppen, indem man z. B. größere Aufgaben aufteilt in kleinere und diese dann jeweils als Tickets verarbeitet.
  • Repository – ein Repository ist eine Instanz von Fossil. Der Begriff kommt von der Verwendung als Versionskontrollsystem, allerdings kann man Fossil auch gut ohne Versionskontrollsystem benutzen und nur das Wiki bzw. Ticketsystem.
  • Commit – Ein einzelner Eintrag in Fossil, z. B. eine hochgeladene Datei oder mehrere Änderungen, wenn sie so zusammengefasst werden (Kommando fossil commit).
  • Timeline – damit bezeichnet Fossil alle bisher gemachten Änderungen, d. h. alle Commits.

Die restlichen Begriffe wie Branches oder Tags muss man nicht kennen, um Fossil als Wiki zu benutzen, und wer sie für das Versionskontrollsystem braucht, wird sie sehr wahrscheinlich bereits kennen.

Installation

Um bei uns ein Fossil-Repository anzulegen, muss man sich im Service-Webinterface anmelden und dort auf “Fossil-Repository anlegen” klicken (bzw. “Fossil-Repository löschen”, wenn man es löschen möchte). Achtung: Es wird nicht nochmal nachgefragt, ob diese Änderung auch übernommen werden soll!

Nach spätestens 30 Minuten liegt dann das Repository unter https://vcs.in-berlin.de/SITENAME_REPONAME bereit, wobei SITENAME der Sitename ist und REPONAME der gewählte Name des Repositorys. Als Benutzer ist zuerst der Benutzer admin angelegt mit dem Passwort, das man bei der Erstellung eingegeben hat. Wir empfehlen, den Benutzer und das Passwort zeitnah zu ändern.

Man sollte sich zuerst die Konfiguration von Fossil ansehen. Dort kann man das Design anpassen, Benutzern Zugriffsrechte geben, usw. Vieles ist anpassbar und sollte der eigenen Benutzung angepasst werden (z. B. wer committen darf, wer sich das Repository kopieren darf, etc.).

Benutzung

Fossil hat vielfältige Anwendungsmöglichkeiten. Wir stellen nachfolgend die vier großen Anwendungsfälle einzeln vor.

Auf eine genaue Beschreibung der Benutzerverwaltung gehen wir hier nicht ein. Diese ist halbwegs selbsterklärend und sehr umfassend, sodass man sich selber kurz durchklickt oder auf die offizielle Fossil-Webseite schauen kann.

Als Versionskontrollsystem

Primär ist Fossil immer noch ein verteiltes Versionskontrollsystem. Es eignet sich gut, um seine Software zu verwalten und schnell anderen Leuten bereitzustellen. Dafür sind nur wenige Klicks im Browser erforderlich. Die Bedienung von Fossil entspricht weitestgehend derer anderer Versionskontrollsysteme, fossil commit zum Übertragen von Änderungen, fossil update zum Aktualisieren des lokalen Repositorys, fossil init zum Aufsetzen eines neuen Repositorys, etc.

Seine Verteilung läuft ungefähr so wie bei git. Man hat diverse Branches, die man miteinander teilen kann, kann sie von Repository zu Repository pushen, etc.

fossil help ist der umfangreiche Hilfebefehl, mit dem man sich die Details zu jedem Kommando anzeigen lassen kann. Für weitergehende Benutzung und Details sei auf die sehr gute Dokumentation von Fossil verwiesen, hier nur eine kurze Referenz:

  • fossil clone $URL $REPO – Kopiert das Repository von $URL in das Repository $REPO (das ist eine einzige SQLite-Datei).
  • fossil open $REPO – öffent das Repository $REPO an der aktuellen Stelle, ggf. kann man danach noch die Revision angeben, die geöffnet werden soll.
  • fossil close – schließt ein aktuell offenes Repository
  • fossil commit – committet den aktuellen Checkout
  • fossil update – aktualisiert den Inhalt des aktuellen Repositories
  • fossil add, fossil delete, fossil mv – Dateien dem Repository hinzufügen, löschen bzw. verschieben
  • fossil settings autosync – Autosync festsetzen, d. h., ob ein Commit automatisch an den Server gepusht werden soll oder nicht
  • fossil push, fossil pull, fossil sync – Inhalte vom lokalen Repository auf das ferne Repository pushen bzw. davon holen, oder beides
  • fossil info – zeigt Infos zum Repository bzw. aktuellen Checkout
  • fossil ui – startet lokal einen Webserver und öffent im konfigurierten Browser die Webseite dazu, sodass man das Repository auch per Maus verwalten kann, Einstellungen vornehmen, usw.

Als Ticketsystem

Fossil lässt sich auch sehr einfach als Ticketsystem und damit gut zur Arbeitsorganisation verwenden. Wenn man Benutzer angelegt hat, kann man diesen je nach Status erlauben, Tickets anzulegen, zu schließen, zu bearbeiten, zu löschen, etc. Man sollte nicht jedem erlauben, Tickets anzulegen, sondern mindestens einen anonymous Login davorschalten, da sonst sehr schnell sehr viel Spam aufkommen kann.

Wenn man oben auf Tickets klickt, kommt man auf die Übersicht. Als Administrator kann man sich entweder alle Tickets anzeigen lassen oder neue Tickets erstellen. Beim Erstellen hat man eine Maske, in der die einzelnen Parameter (wie kritisch ist das Ticket, worum geht es, etc.) bearbeiten kann. Bei der Ansicht aller Tickets kann man sich dann einen Überblick verschaffen und die Tickets nach Anklicken bearbeiten, genauer anschauen, oder löschen.

Als Wiki

Fossil hat ein integriertes Wiki, das man durch Klick auf Wiki erreicht. Dort kann man entweder die Startseite des Wikis bearbeiten, sich die letzten Änderungen anzeigen lassen, eine neue Wikiseite anlegen, einen Blogeintrag anlegen (s. u.) oder auch einfach alle Wikiseiten anzeigen lassen.

Fossil hat seine eigene Syntax, die unter Formatting rules for wiki beschrieben ist. Man kann auch generell HTML erlauben, sollte damit aber vorsichtig sein (“Admin”, “Configuration”, “Use HTML as wiki language”). Die Sandbox ist dazu da, dass man die Syntax ausprobieren kann. Die Syntax ist sehr primitiv, reicht aber für die meisten Dinge aus.

Als Blog

Fossil ist zwar kein Blog, aber man kann es auch so benutzen. Wenn man auf Wiki klickt, dann kann man dort Events erstellen. Diese Events sind quasi Blogeinträge, die danach in der Timeline zu sehen sind. Mit Create a new event erstellt man ein neues Event, d. h. einen Blogeintrag.

Die Benutzung als Blog ist nicht so intuitiv, aber man kann es machen, wenn man eine sehr schnelle Lösung sucht, die v. a. von mehreren Leuten einfach zu benutzen ist.