VersioningStarterDe

Einstieg in NetBeans: Versionierung

Motivation

Während der aktiven Entwicklung ruht sämtlicher Code im Allgemeinen im Dateisystem auf der Festplatte der Entwickler-Workstation. Was in diesem Moment durchaus logisch und sinnvoll erscheint, ist ganz und gar nicht mehr wünschenswert, wenn die Projekte eine gewisse Größe erreichen, selbst wenn nur ein Entwickler aktiv am Code arbeitet:

  • Nicht selten wird es erforderlich sein, parallel zur potentiell immer "defekten" Entwicklungsversion, in der neue Features umgesetzt und ausprobiert werden, eine "stabile" Codebasis zu pflegen, auf deren Basis kleine Verbesserungen umgesetzt und Problem-Berichten von Kunden auf den Grund gegangen wird.
  • Mitunter wird es ebenso erforderlich sein, nach umfassenden Änderungen über potentiell viele Programmdateien hinweg einen Teil dieser Änderungen ab einem gewissen Zeitpunkt rückgängig zu machen, ohne den gesamten Stand zurückzusetzen.
  • Unter Umständen liegt dieser Schritt, zu dem zurückgegangen werden muß, mehrere Monate zurück.

Ausschließlich dateibasierte Ablagestrukturen und Datensicherungen helfen hier nur bedingt. Ein guter Ansatz zur Lösung des Problems ist die Einführung einer Software zur Versionsverwaltung. NetBeans, wie das Gros der modernen IDEs, unterstützt verschiedene Werkzeuge dieser Art.

Werkzeuge

'Local History'

Seit NetBeans 6.0M7 ist das 'Local History' - Feature fester Bestandteil von NetBeans, welches im Grunde genommen eine sehr einfache Versionierung für Daten in NetBeans-Projekten bereitstellt: Bei (gespeicherten) Änderungen an Dateien werden automatisch vorhergehende Versionen als eine Art 'persistentes Undo' vorgehalten, einmal vorgenommene Änderungen können somit leicht rückgängig gemacht werden. Gleichermaßen erlaubt die IDE die Wiederherstellung von gelöschten Files sowie den Vergleich von gespeicherten Ständen untereinander:

File:VersioningStarterDe/vers-01-localdiff VersioningStarterDe.jpg

Insgesamt stellt die 'Local History' schon wegen ständiger, konfigurationsloser Verfügbarkeit ein nützliches Werkzeug dar, welches im Notfall enorm hilfreich sein kann. In größeren Projekten kann dieses jedoch kein "richtiges" Versionsverwaltungs-System ersetzen schon aus einem einfachen Grund heraus: 'Local History' arbeitet dateibezogen; mithin kann stets nur in der Versionsgeschichte einer einzelnen Datei gearbeitet, nicht jedoch etwa ein gesamtes Projekt auf den Stand zu einem gewissen Zeitpunkt zurückgesetzt werden. Während dies für eine irrtümliche Änderung in einem .java-File angenehm ist, will man auf diese Weise nicht Änderungen revertieren, die sich über Hunderte von verschiedenen Dateien in verschiedenen Projekten erstrecken.

CVS

Das Concurrent Versioning System ist eines der am weitesten verbreiteten Versionsverwaltungs-Systeme, wird nach wie vor gerade im Umfeld der Entwicklung von Open-Source-Anwendungen (beispielsweise auf Sourceforge) massiv eingesetzt. CVS war das erste Versionierungs-Werkzeug, welches in NetBeans standardmäßig unterstützt wurde.

Subversion

Die Tatsache, daß CVS trotz seiner Verbreitung gewisse Nachteile mit sich bringt (u.a. im Hinblick auf die Versionierung von Binärdateien sowie die fehlende Transaktionsunterstützung), war ursprünglich der Grund für die Entwicklung von Subversion, das explizit als Nachfolger von CVS angedacht ist und viele dieser Schwächen kompensiert. Trotz verschiedener Kritikpunkte (etwa der Tatsache, daß, im Gegensatz zu CVS, das Repository keine einzelnen Dateien, sondern eine BerkeleyDB-basierende Datenbank und entsprechend nur mit speziellen Tools zu handhaben ist) stellt Subversion dieser Tage ein robustes und verläßliches Versionsverwaltungs-System dar und wird von NetBeans seit Version 5.5 unterstützt.

Mercurial

Als relativ neues System wird in NetBeans 6 auch Mercurial als dezentraler, relativ neuer Ansatz der Versionsverwaltung unterstützt, nicht zuletzt aus dem Grund, daß seit einiger Zeit auch die Migration der NetBeans-Sources dorthin vorgenommen wird. Im Gegensatz zu SVN oder CVS existiert in Mercurial nicht die Wahrnehmung eines "zentralen" Repository und lokaler "Arbeitskopien" auf den Maschinen der Nutzer; vielmehr existieren unter Umständen mehrere Repositories auf mehreren Maschinen, zwischen denen der Abgleich auf Change-Set - Basis erfolgt.


Versionierung mit SVN

Bekanntlich sind sowohl CVS als auch Subversion, obwohl im Wesentlichen in Verbindung mit Repository-Servern bekannt, auch in der Lage, Versions-Bestände in Verzeichnissen auf einer lokalen Festplatte vorzuhalten. Exemplarisch soll daher die Nutzung von Versionierung in NetBeans 6.0 demonstriert werden anhand eines lokalen Subversion-Repositories.

Anforderungen

Für Subversion muß die Arbeitsumgebung zwei Bedingungen erfüllen, um dieses VM-System mit NetBeans nutzen zu können:

  • Das Subversion-Plugin in NetBeans ist installiert. So dem nicht so ist, kann dies über "Tools"->"Plugins" jederzeit nachgeholt werden.
  • Auf dem verwendeten System ist Subversion selbst für die jeweilige Plattform installiert, konkret müssen die Kommandos
    svn
    und {svnadmin} in einer Konsole / Eingabeaufforderung ausführbar sein. Auf Linux-Distributionen sollte dies sinnvollerweise über die distributionseigene Paketverwaltung geschehen.
Neben dem Erfordernis, ein lokales Repository zu erzeugen, setzt auch das NetBeans-SVN-Modul direkt auf den
svn
-Werkzeugen der zugrundeliegenden Plattform auf, was den Vorteil hat, daß die Versionierung für von NetBeans verwaltete Projekte auch ohne NetBeans mit "SVN-Bordmitteln" einfach möglich ist.

Erzeugung des lokalen Repositories

Mit dem Befehl
svnadmin create local
läßt sich schnell ein SVN-Versionsbestand erzeugen, der aus NetBeans heraus nutzbar ist. Im Beispiel wird das Repository als Unterverzeichnis von $HOME/.repository/ erzeugt und "local" benannt. Danach findet sich im bewußten Verzeichnis die Struktur, die in Folge die Versionen des Codes aus dem Beispielprojekt aufnehmen wird:

File:VersioningStarterDe/vers-02-localrep VersioningStarterDe.jpg


Import eines leeren Beispielprojektes

Um das lokale Repository mit Leben zu befüllen, soll ein leeres Projekt in NetBeans erstellt werden, im Beispiel vom Typ 'Java Application', allerdings ohne eine Hauptklasse zu erzeugen:

File:VersioningStarterDe/vers-03-emptyproject VersioningStarterDe.jpg

Im Ergebnis entsteht ein leeres Projektverzeichnis mit grundlegender NetBeans-Build-Infrastruktur für Sources und Tests sowie zwei angehängten JUnit-Libraries. Um den Effekt von Versionierung im Hinblick auf Änderungen zu testen, soll das Projekt schon in diesem leeren Urzustand in das lokale Repository eingepflegt werden. Dies geschieht über Rechtsklick auf das Projekt -> 'Versioning' -> 'Import into Subversion Repository',...

File:VersioningStarterDe/vers-04-importproject VersioningStarterDe.jpg

... worauf der SVN-Assistent zur Anzeige kommt und zunächst um Eingabe des URL zu einem existenten Repository bittet (SVN-Bestände lassen sich über verschiedene Protokolle erreichen, u.a. HTTP, SSH, FTP oder eben auch lokalen Dateisystem-Zugriff). Hier ist auf das vorangehend erzeugte lokale Leer-Repository "local" zu verweisen:

File:VersioningStarterDe/vers-05-addrepo VersioningStarterDe.jpg

Fortsetzend mit "Next", erwartet die IDE die Eingabe einer 'Commit Message', die als Text mit der in das Repository importierten Version des Codes gespeichert wird und im "Ernstfall" Aussagen über die Änderungen seit der letzten Version beinhalten sollte:

File:VersioningStarterDe/vers-06-commitmessage VersioningStarterDe.jpg

Im Folgenden ('Next') können dann die Dateien und Verzeichnisse ausgewählt werden, die mit dem Projekt in das Repository zu importieren sind. Im gegenwärtigen, neu erzeugten, leeren Java-Projekt ist dies bislang nur die Infrastruktur, die NetBeans für Verwaltung und Build benötigt:

File:VersioningStarterDe/vers-07-files VersioningStarterDe.jpg

Bedarfsweise können hier auch (über Auswahl einer entsprechenden 'Commit Action') Dateien vom Import ausschließen, was insbesondere dann interessant ist, wenn beispielsweise
maven2
-Projekte "pur", ohne IDE-spezifische Projektinformationen, versioniert werden sollen. Nach Abschluß mit "Finish" wird der Import der Dateien durch {svn} tatsächlich vorgenommen. Danach ist das Projekt lokale Arbeits-Kopie eines SVN-Repositories, was sich an verschiedenen Punkten erkennen läßt:
  • Der Eintrag 'Versioning' im Kontext-Menü des Projektes ist verschwunden und durch das 'Subversion'-Menü ersetzt worden, über welches nunmehr SVN-spezifische Aktionen am Projekt aufgerufen werden können.


File:VersioningStarterDe/vers-09-history VersioningStarterDe.jpg

  • Über den Menü-Eintrag 'Subversion' -> 'Search History' ist es möglich, die Versionsgeschichte des Projektes zu durchsuchen, ein Klick auf 'Search' ohne Angabe von Parametern zeigt dem gesamten Verlauf.

File:VersioningStarterDe/vers-10-history2 VersioningStarterDe.jpg

  • An der Konsole läßt sich im Verzeichnis des Projektes derselbe Effekt unter Verwendung von
    svn
    erzeugen:

File:VersioningStarterDe/vers-11-history3 VersioningStarterDe.jpg


Code-Commit

Um die Versionierung in Aktion zu sehen, soll nun Code in das Projekt eingeführt werden in Form einer Klasse
MyApplication
über Rechtsklick auf 'Source Packages' im Projekt -> 'New' -> 'Java Class':

File:VersioningStarterDe/vers-12-addclass VersioningStarterDe.jpg

Mit 'Finish' erzeugt der Assistent sowohl das erforderliche Java-Package als auch die Datei
MyApplication.java
im Projekt, womit sich das Projekt-Verzeichnis im Vergleich zu der im SVN-Repository gespeicherten Version ändert. Die IDE zeigt dies auch sofort an (Eine vollständige Liste der Versioning-Markierungen und -Farben findet sich in der offiziellen (englischen) 'Guided Tour of Subversion...' in der NetBeans-Knowledge-Base):

File:VersioningStarterDe/vers-13-classadded VersioningStarterDe.jpg

  • Der blaue Container am Projekt, an 'Source Packages' und dem Paket 'demo.netbeans.core' weist darauf hin, daß jeweils ein untergeordnetes Element im Vergleich zur letzten gespeicherten Version Änderungen erfahren hat.
  • Gleichermaßen ist 'MyApplication.java' in grün dargestellt, Hinweis auf eine Datei, die in der lokalen Arbeitskopie im Vergleich zum Repository seit der letzten Version hinzugefügt wurde.

Um diese Änderung ins Versioning-Repository zu übertragen, ist die Option 'Commit' im Menü 'Versioning' oder im 'Subversion'-Kontextmenü des Projektes zu wählen, worauf ein Assistent in schon bekannter Struktur die Möglichkeiten bietet, eine Commit Message anzugeben sowie für die seit der letzten Version geänderten Dateien auszuwählen, ob und wie diese in die Versionierung importiert werden sollen. Es zeigt sich:

File:VersioningStarterDe/vers-14-commitclass VersioningStarterDe.jpg

Mit dem Einfügen der Klasse in das definierte Paket werden die damit verbundenen Verzeichnisse sowie die .java-Datei neu in den Bestand aufgenommen (die Änderung an
nbproject
ist verbunden mit der Tatsache, daß das Projekt in Versionierung aufgenommen wurde, und soll daher ignoriert werden):

File:VersioningStarterDe/vers-15-commitoutput VersioningStarterDe.jpg


Versioning für andere Dokumente - Favorites

In der Arbeit mit Code-Projekten ist die Verwendung von Versionierungs-Systemen leicht einsehbar. Darüber hinaus bieten jedoch sowohl Werkzeuge wie Subversion als auch die NetBeans-IDE die Möglichkeit, neben Programmcode quasi beliebige Datei- und Ordnerstrukturen in einem zentralen Repository abzulegen.

Dafür ist zunächst, im "Favorites"-Fenster, über Rechtsklick -> "Add to Favorites" das bewußte Basis-Verzeichnis zu den Favoriten hinzuzufügen (im Beispiel das Verzeichnis, in dem ich die Screenshots für diese Tutorials speicher) , ...

File:VersioningStarterDe/vers-16-fave VersioningStarterDe.jpg

... bevor über "Versioning" -> "Subversion" -> "Import into Repository" das Verzeichnis in Versionierung übernommen werden kann:

File:VersioningStarterDe/vers-17-import VersioningStarterDe.jpg

Hierbei ist zu berücksichtigen: Anders als im "Projects"-Window ist diese Möglichkeit in "Favorites" nicht über das Kontext-Menü des Ordners verfügbar, sondern nur über das Hauptmenü der IDE. Dies gilt indes nur für den erstmaligen Import - ist das Verzeichnis einmal versioniert, läßt sich wie gewohnt die Subversion-Funktionalität über Rechtsklick auf das Verzeichnis aufrufen:

File:VersioningStarterDe/vers-18-syncfave VersioningStarterDe.jpg

Im Nachgang läßt sich der Datenordner wie ein beliebiges Code-Projekt über das Repository versionieren. Was zunächst wie Spielerei und eher "Nebenaspekt" einer Technik wirkt, die eben doch vorrangig bei der Software-Entwicklung zum Einsatz kommt, läßt sich durchaus plausibel als "sinnvoll" begründen:

  • Zum einen besteht in allen ernsthaften Installationen das Problem der Datensicherung, wobei idealerweise verschiedene Stände derselben Daten gesichert werden sollen. Das Backup eines SVN-Repositories mag dies auf sehr simple Weise zu realisieren in Situationen, in denen bessere Werkzeuge nicht verfügbar oder gewünscht sind.
  • Bei Sicherung etwa von Konfigurationsdateien bietet die Verwendung eines zentralen Repositories mit verschiedenen Versionen eine netzweit standardisierbare Ablagemöglichkeit, in der sowohl Änderungen an Einstellungen per kommentiertem Commit dokumentiert werden als auch jederzeit einfach wieder herstellbar sind, ohne etwa mit lokalen "Sicherungskopien" von Konfigurationsdateien arbeiten zu müssen.


Weiterführende Informationen

  • Guided Tour of Subversion for NetBeans IDE 6.0 in der offiziellen NetBeans Knowledge Base bietet sehr viel detaillierter Informationen zum Versioning, der Oberfläche und weitergehenden Features (Branching, Merging, ...), ebenfalls am Beispiel Subversion.
Not logged in. Log in, Register

By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo