Subversion | Important Stuff

In diesem Post möchte ich einige Dinge, die mir bezüglich Subversion wichtig sind, zusammenfassen. Ich habe bereits einmal die Unterschiede zwischen CVS und Subversion aufgezählt und möchte auf diesen Post hier noch einmal verweisen. CVS vs. Subversion

Und los gehts:

Parallele Änderungen an Dateien:

• Subversion verwendet den Check-out nur zur Erstellung der Arbeitskopien und man muss Dateien mit einem separaten Lock-Befehl sperren.
• Sobald eine Datei im Repository gesperrt ist, werden weiter Lock-Befehle mit einer Fehlermeldung quittiert.
• Die Freigabe erfolgt entweder mit einem separaten Befehl (Unlock) oder beim Check-in.
• Subversion beherrscht seit Version 1.2 sowohl Copy-Modify-Merge als auch Lock-Modify-Unlock, man kann hier also pro Konfigurationselement entscheiden, welche Methode besser geeignet ist.

Tags und Baselines

• Vor einem Refactoring sollte der Zustand eines Projekts festgehalten werden. (Snapshot)
• Im technischen Sinn, gibt es keine Unterschiede zwischen Tags und Baselines.
• Subversion kennt keine separaten Befehle zur Erstellung von Tags oder Baselines im Repository.
• Releases zeichnen sich dadurch ab, dass die Anwender damit arbeiten.

Branches

• Unter einem Peer-Review versteht man die Kontrolle einer Änderung durch einen sachkundigen Gutachter.
• Bei Branches handelt es sich um verzweigte oder parallele Entwicklungspfade.
• Branches sind eine Alternative zu einem linearen Entwicklungspfad.
• Nachteile eines linearen Entwicklungspfades sind die schlechte Ausnutzung der Ressourcen im Projekt und die nicht vorhandene Abdeckung des Zeitraumes nach Erstellung eienr Baseline. Dadurch ist es nicht möglich, kritische Bug-Fixes für ein produktives Release separat auszuliefern, da im Entwicklungspfad ja schon die erweiterte Funktionalität des Folge-Releases implementiert wird.
• Irgendwann müssen alle im Release-Brunch durchgeführten Änderungen und Bug-Fixes auch in den Trunk übernommen werden. Die beiden Brunches werden also wieder zusammengeführt.

Änderungsmanagement

• Ein guter Aufsetzpunkt für das Änderungsmanagement ist die erste Baseline im Projekt.

Releasemanagement

• Zu bevorzugen sind Releases, die funktionale Erweiterungen auf der Ebene von Subsystemen bündeln. Jedes Release ändert dadurch schwerpunktmässig nur einen bestimmten Teil des Systems.
• Wird ein System komplett neu entwickelt, bilden statt Change Requests beispielsweise die umzusetzenden Use Cases die Grundlage für die Release-Planung.
• Release-Nummern: Release x.y.z ==> X = Hauptrelease, Y = Wartungsrelease, Z = Patch
• Hauptrelease: Änderungen an verwendeten Dateiformaten, grundsätzliche Überarbeitung der Benutzeroberfläche, komplett neue Subsysteme oder Komponenten, ...
• Wartungsrelease: Fehlerbehebungen, funktionale Erweiterungen mit nur geringen oder keinen Auswirkungen auf den Betrieb des System, ...
• Patches: sollten im Normalfall nicht notwendig sein, ausschließlich zur Fehlerbehebung, Procedere zur Auslieferung eines Patches sollte genau dokumentiert sein da diese oft sehr unerwartet bzw. schnell implementiert werden müssen.

Audits, Metriken und Berichte

• Mit Hilfe von Audits wird in einem KM-Prozess überprüft, ob die KM-Elemente alle an sie gestellten Anforderungen erfüllen.
• Audits vergleichen den Istzustand mit einem vorher festgelegten Sollzustand.
• Pro Audit werden Teilnehmerkreis, der Zeitpunkt und das genau Ziel festgehalten.
• Metriken erlauben differenziertere Aussagen über die Qualität des Systems und den Status des Projektes als Audits, da diese im Prinzip nur boolesche Ergebnisse liefern.
• Es gibt: Produkt~, Projekt~ und Prozessmetriken
• Geziehlte Auswahl von Metriken nach dem GQM-Verfahren (Goal-Question-Metric) am Anfang des Projekts.
• Ausführliche Dokumentation der verwendeten Metriken und Schwellenwerte im KM-Handbuch.
• Metricen liefern nur Hinweise auf mögliche Probleme. Wenn ein Schwellenwert verletzt wird, sollte man ein Quelltext-Audit ansetzen um sich ein genaues Bild von der Lage zu verschaffen. Keinesfalls einfch die "Behebung des Fehlers" fordern.

Subversion

• Subversion erfüllt ACID. (Atomicity, Consistency, Isolation und Durability)
• Sowohl die Server- als auch die Clientkomponenten von Subversion wurde in C auf Basis der Apache Portable Runtime (APR) entwickelt, einer Bibliothek zur Unterstützung der plattformunabhängigen Entwicklung.
• Der Subversion-Client ist nicht auf eine ständige Verbindung zum Repository angewiesen. So kann man beispielsweise im Zug oder Flugzeug problemlos Änderungen an den Dateien im lokalen Arbeitsbereich vornehmen. Auch komplexerer Operationen, wie z.B. die Rücknahme von Änderungen an einer Datei im Arbeitsbereich, werden vorm Client offline durchgeführt. Ermöglicht wird dies durch einen lokalen Cache des Clients, in dem die letzten gültigen Versionen der Dateien aus dem Repository vorgehalten werden.
• Clientkommandos ohne Netzwerkverbindung (runter scrollen)

Arbeitsweise des Subversion Repositories

• Wichtigstes Konzept von Subversion: Revision.
• Subversion vergibt für jede Transaktion, die ins Repository geschrieben wird, eine sequenziell hoch gezählte Revisionsnummer.
• Die Revision kennzeichnet alle im Rahmen der Transaktion geänderten Dateien und Verzeichnisse. Diese Menge der Änderungen wird auch als Changeset der Revision x bezeichniet.
• Weiters markiert die Revision einen bestimmten Stand des gesamten Repositorys, man spricht dann von einem Repository in Revision x.

Erstellung eines Repositories

• svnadmin create D:\path\to\repo
• Standardmässig wird das dateibasierte Storage System fsfs verwendet. Eine Alternative wäre das bdb (Unterschiede siehe Buch Seite 88).
• Vollständige Referenz des svnadmin-Kommandos

Benutzer und Zugriffsrechte

• Subversion erzeugt Repositories standardmässig völlig ungeschützt.
• Sicherheitseinstellungen für ein Repository werden über die Datei svnserve.conf festgelegt. Diese Datei befindet sich im conf-Verzeichnis des Repositorys.
• Nach dem Anlegen eines neuen Repositories enthält diese Datei nur auskommentierte Zeilen.
• svnserve beherrscht nur einen sehr einfachachen Authentifizierungsmechanismus und bedeutet, dass die users.conf Datei sowohl Usernamen als auch Passwörter in Klartext enthält.
• access.conf: Zugriffsrechte auf das Repository pro User und abhängig von der Projektstruktur.
• Berechtigungen in der access.conf werden an Unterverzeichnisse vererbt. Z.B. [/] Dies bedeutet oberste Ebene und spricht das komplette Repository an.

Auf der folgenden Abbildung kann man eine erste Konfiguration meines Beispiel-Repositories erkennen. Es werden die svnserve.conf, die access.conf und die users.conf dargestellt.

From Misc

• Als Berechtigungen kann entweder ein r (lesender Zugriff), rw (lesenser und schreibender Zugriff) oder ein Leerzeichen (kein Zugriff) eingetragen werden.

Zugriff auf das Repository

• Starten des Subversion-Servers svnserve: svnserve -d -r d:\path\to\repository
• Zugriff auf das Repository über den SVN-Client svn: svn list svn://YOUR_ADDRESS/repo

Notiz: In meinem Fall sieht die Ordnerstruktur so aus, dass ich auf meinem D-Laufwerk ein Verzeichnis svn-repos angelegt habe, und in diesem hab ich eine test-repo mittels svnadmin angelegt. Um nun auf dieses zugreifen zu können, muss man svnserve -d -r svn-repos aufrufen und nicht das test-repo selbst.

• Die Angabe des Repositories im Anschluss auf das svn://HOSTNAME/ bezieht sich auf das beim Start von svnserve angegebene Basisverzeichnis.

Tags und Branches

• Bezeichnungstemplates für Branches und Tags Buch Seite 94.
• Tags sind unveränderlich, Branches stellen echte Projektverzweigungen dar und können mit trunk zusammengeführt werden.
• Tags nur lesend für Developer zugreifbar machen. (access.conf)

Subversion Properties am Client

• Geltungsbereich entweder einzelne Datei aber auch komplettes Verzeichnis.
• Properties wirken jedoch nicht rekursiv, d.h. sie müssen Unterverzeichnissen explizit zugewiesen werden.
• Vordefinierte Properties: svn:name
• WIchtige Properties: svn:mime-type, svn:eol-style, svn:needs-lock
• svn:mime-type: Unterscheidung zwischen Textdateien und Binärdateien für Subversion. Wird mime-type nicht explizit gesetzt, verwendet Subversion für binäre Dateien standardmässig application/octet-stream. Textdateien erhalten per Default keinen MIME-Typ.
• svn:eol-style: Umgang von Subversion mit Zeilenendmarkierungen von Textdateien. Sinnvoll meißtens die Einstellung native, da Subversion in diesem Fall die Zeilenendmarkierung automatisch an die Bedürfnisse des verwendeten Betriebssystems anpasst.
• svn:needs-lock: Steuert welche Dateien zwingend mit dem Lock-Modify-Unloc-Ansatz bearbeitet werden müssen. Dieses Property besitzt keinen Wert, die alleinige Zuweisung zu einer Datei ist ausreichend.
• svn propset: Setzen einer Property für eine Datei mittels svn-Client.
• svn propdel: Löschen einer Property mittels svn-Client.
• Lokale Konfigurationsdatei: Referenz

Die folgende Abbildung zeigt eine Beispiel-Config Datei meiner Subversion-Konfigurationsdatei am Client:

From Misc

Anlegen der Struktur im Repository

• In einem temporären Verzeichnis die Struktur anlegen und gleiche Verzeichnis folgendes Kommando aufrufen:
• svn import svn://localhost/name_des_repositorys -m "Import der Projektstruktur" --username UN --password PW
• Das Änderungskommentar wird in der Versionshistorie der von den Änderungen betroffenen Verzeichnisse und Dateien hinterlegt.
• TODO