Versionskontrollsysteme

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 User muss man den Support kontaktieren.

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

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

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.

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

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 einloggt, dann auf Admin geht, auf Users und dann auf den Adminuser (Standard ist admin). Dort kann man das Passwort setzen (Achtung: Es wird nicht nochmal bestätigt!).

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. Siehe auch den Eintrag in der Wikipedia.
• 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. Siehe auch Wikipedia.
• Repository – ein Repository ist quasi 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. Siehe auch Wikipedia.
• 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 Begrife wie Branches oder Tags muss man nicht kennen, um Fossil als Wiki zu benutzen, und wer sie für das Versionskontrollsystem braucht, wird sie eh schon kennen.

Um bei uns ein Fossil-Repository anzulegen, muss man auf das Service-Webinterface gehen und dort auf Fossil-Repository anlegen klicken (bzw. Fossil-Repository löschen, wenn man es löschen will). 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 User ist zuerst der User admin angelegt mit dem Passwort, das man anfangs eingab. Man sollte nach Möglichkeit bald den User und das Passwort ändern.

Man sollte sich zuerst die Konfiguration von Fossil angucken. Dort kann man das Design anpassen, Usern 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.).

Fossil hat vielfältige Anwendungsmöglichkeiten, daher hier die vier großen einzeln vorgestellt.

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

Primär ist Fossil immer noch ein verteiltes Versionskontrollsystem. Es eignet sich eben super, um seine Software zu verwalten und schnell anderen Leuten bereitzustellen, das sind nur wenige Klicks im Browser. Die Bedienung von Fossil entspricht weitestgehend der der anderen VCSe, =fossil commit= zum Committen, =fossil update= zum Updaten, fossil init zum Aufsetzen eines neuen Repositorys, etc.

Seine Verteilung läuft ungefähr so ab 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 – updatet 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.

Fossil lässt sich auch sehr einfach als Ticketsystem, und damit gut zur Arbeitsorganisation verwenden. Wenn man User 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 aufkommt.

Wenn man oben auf Tickets klickt, kommt man auf die Übersicht. Als Administrator kann man sich entweder alle Tickets anzeigen lassen oder neue 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 angucken, oder löschen.

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 angucken, 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 ein bisschen mit der Syntax rumspielen kann. Die Syntax ist sehr primitiv, reicht aber für die meisten Dinge aus.

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 einen neuen 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.