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

Maven & Co

Today, I decided to set up myself a reference-environtment with the following technologies and how you have to configure this tools that they work properly together. The following list shows all technologies and their versions I've used to set up this environment:

• Java 1.6
• Maven 2.0.6
• Subversion 1.4.3
• Continuum 1.0.3
• Artifactory 1.2.1-RC0
• XAMPP 1.6.1 (For project-website)

Reference-Project Bookstore

My plan is to develop an online bookstore just to show how maven works with a small web-app which consists of some submodules. In this first post I'd like to show only the build-configuration settings for this web-app. First I created a file structure where to store all my tools, projects and their settings. I created the following folders:

• Continuum (my Build-Server)
• Locals (my local maven-repository)
• Projects (all my projects)
• Proxies (all maven-proxies => e.g. Artifactory)
• SVN (my Suversion-Repository)

The following picture shows the file-structure. I haven't collapse all folders because those are just some configuration-specific folders of the tools.

From Maven

All folders marked green are ander Subversion source-control. After I created this structure I had to create a subversion-repository. You just have to invoke the command 'svnadmin create path/to/your/custom/folder' and then import your structure with 'svn import /path/to/repo/ -m "some message"'. Then you have to checkout the project for the first time with 'svn checkout /path/to/repo'.


If everything works fine you can now set up you Continuum build-server to interact with your subversion-repo. This server will execute a specific maven commands (which you will be able to configure) to a certain time (cron job syntax) so you always will haven an overview of the checked in sources and if the application is clean.

There is one custom configuration you have to do if you would like to use the file-protocoll when you would like to set the path to your project's pom-file. By default the file-protocoll is turned off but you can turn it on by setting the 'allowedScheme'file'allowedScheme' in the application.xml of continuum which you will find in the CONTINUUM_HOME\apps\continuum\conf folder.

From Maven

After changing this property everything should work fine. Now you will be able to set up a maven-proxy which enables you to share your application and other artefacts with more developer.

From Maven

Artifactory is really easy to configure but I'm still a bit confused about some settings. I'm going to write about it in upcoming posts. There is only one thing, if you are behind a proxy you have to configure it in the artifactory.config.xml which you can find in the etc-folder of your Artifactory-installation. The following screenshots show some interesting maven-settings about the scm-Tag (Subversion) and the distributionManagement-Tag which configures the path to the snapshot-repository where you can deploy your snapshot-releases to the Artifactory repositories.

From Maven

From Maven

The last thing is to install a webserver where you can deploy your project-site. I have installed Xampp for this kind of purpose. You just have to confiugre your site-tag within your distributionManagement-Tag and then after invoking the mvn site:site site:deploy command your complete project-site will be generated and transfered to your configured path.

So now you have set up a good infrastructure to develop your application and can concentrate on your application logic. In upoming posts I will begin to design my bookstore-application and try to solve the remaining build-configuration-issues.

Of course you're welcome to descripe your best-practices with this kind of technologies and I also would like to mention the fact that this is not a complete description but should give you an idea on how to set up a possible way for a building-environment for a Java-based web-application.

Cheers

SVN 1.4.3 | How to...

... install under Windows XP:

1. Binaries 4 Windows XP downloaden: Subersion 1.4.3
2. Entpacken und SVN_HOME zu Umgebungsvariablen hinzufügen.
3. svn --version über Command-Line testen.

Ein Repository-Struktur auflisten:

• svn list -v http://pfad/zum/respository --username un --password pw

CVS vs Subversion

Schwächen von CVS:

• Es können nur einzelne Dateien und nicht komplette Verzeichnisse versioniert werden.
• Umbenennen, Kopieren, Verschieben und Löschen von Dateien kann nicht in der Versionshistorie aufgenommen werden.
• Fehlende Unterstützung von Transkationen => Inkonsistenz im Repository

Wichtigsten Funktionen von Subversion:

• Versionierung von Dateien und Verzeichnissen.
• Atomare Check-ins. => Unterstützung von Transaktionen.
• Unterstützung von mehreren Servervarianten und Kommunikationsprotokollen.
• Effizienter Algorithmus zur Deltabildung. (Keine Unterscheidung zw. Text- & Binärdat.)
• Leistungsfähiges Branching und Tagging. (Cheap Copies)

Links:

• Subversion