Subversion HOWTO

Aus Freifunk Leipzig
Wechseln zu: Navigation, Suche

Subversion ist ein Programm zum Verwalten von Sourcecode. Wir nutzen es bei Freifunk, um mehreren Entwicklern das gleichzeitige Weiterentwickeln der Firmware zu ermöglichen.

Inhaltsverzeichnis

Wie es funktioniert

Subversion besteht immer aus zwei Komponenten - dem Subversion Server und der lokalen Kopie. Auf dem Server wird die jeweils aktuelleste Version und alle alten Versionen der zu entwickelnden Software gespeichert, diese Kopie nennt man auch "Repository". Auf dem lokalen Rechner ist nur jeweils eine sogenannte Arbeitskopie gespeichert. Jeder Entwickler hat eine eigene solche Arbeitskopie auf seinem Rechner, die er dann weiterentwickelt. Das erstmalige Anlegen der Arbeitskopie nennt man "Checkout". Wenn ein Entwickler eine größere Erweiterung beendet hat, spielt er die Änderungen auf den Server auf. Dies nennt man "Commit". Andere Entwickler können dann die Änderungen vom Server laden und in ihre Arbeitskopie einfügen, dies nennt man "Update". All dies wird durch Subversion automatisiert. Beim Commit berechnet Subversion die Unterschiede der bearbeiteten Arbeitskopie zur Vorversion und spielt nur die Änderungen zum Server. Analog analysiert Subversion beim Update die Unterschiede der lokalen Arbeitskopie zur letzen auf dem Server gespeicherten Version und lädt automatisch alle geänderten Dateien herunter um die Arbeitskopie auf den aktuellen Stand zu bringen. Auf diese Weise können viele Entwickler gleichzeitig an der gleichen Software arbeiten.

Konflikte beim Bearbeiten

Solange alle Entwickler nur an jeweils verschiedenen Dateien arbeiten, funktioniert das System problemlos. Was aber passiert, wenn mehrere Entwickler gleichzeitig an der gleichen Datei arbeiten? Auch dies kann Subversion bewältigen, solange die Datei eine reine Textdatei ist. Das folgende Beispiel soll kurz zeigen, wie Subversion dieses Problem löst. Angenommen wir haben zwei Entwickler John und Jane, beide haben in ihrer Arbeitskopie eine Datei "neues.txt", welche die neuesten Informationen zur Firmware beinhaltet.

Neues in der Firmwareversion 2.10

- Nodes können jetzt über 20 km senden.
- Stromverbrauch um 50% gesenkt.


Dies ist noch die Version aus der alten Firmware und soll jetzt auf den aktuellen Stand gebracht werden. John hat das Modul für die Reichweitenvergrößerung geschrieben und ändert die Datei auf folgenden Stand.

Neues in der Firmwareversion 2.20

- Nodes können jetzt über 30km senden.
- Nodes können jetzt auch um die Ecke senden.
- Stromverbrauch um 50% gesenkt.

Er macht einen Commit und damit wird diese Version die aktuellste auf dem Server. Jane hat das Stromsparmodul geschrieben und ändert wenig später ihre Arbeitskopie, noch basierend auf der alten Version:

Neues in der Firmwareversion 2.20
 
- Nodes können jetz über 20km senden.
- Firmware hat jetzt den grünen Punkt.
- Stromverbrauch um 60% gesenkt.

Jetzt macht Jane einen Commit und erhält eine Fehlermeldung von Subversion, daß auf dem Server bereits eine neuere Version dieser Datei vorliegt. Jane muß also zuerst ein Update machen. Ohne Subversion wären jetzt ihre Änderungen verloren. Subversion kann jedoch textbasierte Dateien zusammenführen. Diesen Vorgang nennt man "Merge". Dazu analysiert Subversion, welche Zeilen jeweils aktueller sind, und fügt aus den jeweils aktuellsten Zeilen das neue Dokument zusammen. In unserem Fall passiert folgendes: Die erste Zeile auf dem Server und die in Janes Kopie sind beide gleich aktuell. Da sie aber inhaltlich identisch sind, ist dies kein Problem. Die neue erste Zeile ist also:

Neues in der Firmwareversion 2.20

Die zweite Zeile ist in beiden Versionen unverändert eine Leerzeile, wird also beibehalten. Die dritte Zeile ist in der von John auf dem Server eingespielten Version aktueller, da Jane sie nicht geändert hat, daher gewinnt die Zeile von John:

Neues in der Firmwareversion 2.20

- Nodes können jetzt 30km senden.

Die vierte Zeile stellt ein Problem dar, da sowohl Jane als auch John sie neu eingefügt haben. Subversion kann dieses Problem von selbst nicht lösen, da es nicht entscheiden kann, welche der beiden Versionen aktueller ist. Daher meldet Subversion einen sogennannten "Merge Conflict". In die Datei werden beide Zeilen eingetragen und speziell markiert. Jane kann den Konflikt hinterher manuell lösen:

 Neues in der Firmwareversion 2.20

- Nodes können jetzt 30km senden.
<<<<<< .mine
- Firmeware hat jetzt den grünen Punkt.
=======
- Nodes können jetzt auch um die Ecke senden.
>>>>>> v220

Die letzte Zeile ist in der Arbeitskopie von Jane aktueller, da John sie nicht modifiziert hat. Daher sieht das fertige Dokument zum Schluß folgendermaßen aus:

 Neues in der Firmwareversion 2.20

- Nodes können jetzt 30km senden.
<<<<<< .mine
- Firmeware hat jetzt den grünen Punkt.
=======
- Nodes können jetzt auch um die Ecke senden.
>>>>>> v220
- Stromverbrauch um 60% gesenkt.

Nun muß Jane den Konflikt manuell lösen. In diesem Fall löscht Jane einfach die von Subversion erstellten Marker, da sie alle Zeilen beibehalten will:

 Neues in der Firmwareversion 2.20

- Nodes können jetzt 30km senden.
- Firmeware hat jetzt den grünen Punkt.
- Nodes können jetzt auch um die Ecke senden.
- Stromverbrauch um 60% gesenkt.

Nun muß Jane nur noch committen und auch Ihre Änderungen sind dann auf dem Server gespeichert.

Was brauche ich um loszulegen

Zunächst einmal brauchst Du einen Subversion-Client. Ein guter Client für Windows ist TortoiseSVN, dieser klinkt sich in den Explorer ein und ermöglicht sehr einfaches Updaten und Committen. Für Linux und Mac gibt es Kommandozeilen Clients.

  • Windows: TortoiseSVN
  • Linux: das Paket "subversion" ist auf allen größeren Distributionen enthalten und beinhaltet die Kommandozeilenversion. Für KDE gibt es auch ein Plugin namens kdesvn, welches ähnlich wie TortoiseSVN arbeitet.
  • Mac: den Kommandozeilenclient gibt es auch für Mac. Von Metissian gibt es auch einen graphischen Client.

Weiterhin braucht ihr Zugangsdaten. Diese bestehen aus:

  • Login: Euer Nutzernamen auf dem Subversion Server
  • Passwort: Euer dazu passendes Passwort
  • Repository URL: eine URL die dem Subversion-Client mitteilt, wo das Repository zu finden ist.

Arbeiten mit Subversion

Checkout einer Arbeitskopie

Zuerst müßt Ihr Euch eine lokale Arbeitskopie der Software erstellen. Unter Linux geht dies ganz einfach:

svn co <Subversion URL> --username <Euer Login> --password <Euer Password>

Dies erstellt eine Arbeitskopie des angegebenen Repositories im aktuellen Ordner auf Eurem Rechner. Eine Anleitung zum Checkout einer Arbeitskopie mit TortoiseSVN findet Ihr hier.

Ändern der Arbeitskopie

Nun könnt ihr beliebig Dateien der Arbeitskopie verändern. Die geänderten Versionen werden beim nächsten Commit auf dem Server aktualisiert.

Dateien hinzufügen

Wenn Ihr neue Dateien hinzufügen wollt, müßt ihr dies Subversion mitteilen. Erstellt dazu die neue Datei und teilt dann Subversion mit daß Ihr diese Datei zur Versionierung hinzufügen wollt:

svn add <Dateiname>

Wenn Ihr TortoiseSVN benutzt, ist dies sogar noch einfacher, rechtsklickt einfach die Datei und wählt dann "Tortoise SVN" und "Add". Dies fügt die Datei in die Versionverwaltung ein. Beim nächsten Commit wird diese Datei dann auch dem Repository auf dem Server hinzugefügt.

Änderungen committen

Das Committen Eurer Änderungen ist sehr einfach. Tippt einfach

svn commit

im Stammordner Eurer Arbeitskopie und alle Änderungen Eurer Arbeitskopie werden zum Server überspielt. Ähnlich einfach gestaltet sich das Committen auch mit TortoiseSVN. Hier rechtsklickt Ihr einfach den Ordner in dem sich Eurer Arbeitskopie befindet und wählt dann "Tortoise SVN" und "Commit". Beim Committen werdet ihr nach einer Commit Message gefragt. Dies ist eine kleine Notiz in der Ihr kurz beschreiben solltet, was Ihr geändert habt. Dies ist später hilfreich, wenn Ihr sehen wollt, wer was an der Firmware geändert hat.

Tips & Tricks

Es gibt einige Dinge, die Ihr beachten solltet, wenn Ihr mit Subversion arbeitet:

  • Wenn Ihr nicht weiterwißt oder eine Frage habt, stellt Sie in der Mailingliste statt herumzuprobieren. Lieber einmal zu viel gefragt, als die Arbeit von anderen zerstört.
  • Ihr solltet immer eine Commit Message schreiben, damit andere wissen, was Ihr warum geändert habt.
  • Ihr solltet häufig committen, da je länger Ihr Eure Änderungen behaltet, die Chance größer wird, daß Ihr Euch Merge-Konflikte einhandelt.
  • Ihr solltet nur Dinge committen, die wenigstens für Euch funktionieren. Committet keine halben Stände, da Ihr damit die Arbeitskopie von anderen in einen nicht funktionsfähigen Zustand versetzt. Man nennt dies auch "das Repository zerbrechen". Es ist für alle ärgerlich, wenn ihre Arbeitskopien nicht mehr funktionieren, weil jemand etwas halbgares committed hat.
  • Lest Euch mehr Wissen über Subversion an. Subversion kann noch erheblich mehr als die hier beschriebenen Dinge. Die definitive Referenz ist das SVN Book, leider auf Englisch. Wenn Ihr TortoiseSVN nutzt, sei Euch auch die sehr gute deutsche Dokumentation dazu empfohlen, die viele Fragen klärt.

Links