DEV2DEV

OASIS und Subversion

OASIS-SVN

Dieses Tutorial beleuchtet detailiert die Zusammenarbeit zwischen Access/OASIS und einem Subversion-Server in der Praxis.

Voraussetzungen

• Access 2000, 2002, 2003 oder 2007
• OASIS-SVN
• Webserver mit installiertem Subversion
• TortoiseSVN

Im Beispiel wird als Webserver ein IIS mit Visual-SVN (kostenlos) verwendet.
Das für dieses Tutorial verwendete Repository „Test“ wurde vorab angelegt.
Dabei wurde die in der Praxis übliche Verzeichnisstruktur für ein Repository verwendet (dazu später mehr).

Arbeitsverzeichnis anlegen

Als erstes legen wir in einem beliebigen Laufwerk/Ordner ein neues Verzeichnis „Test“ für unser Projekt an.
Um dieses Verzeichnis erstmalig mit dem Repository zu verbinden, wählen wir im Tortoise-Menü den Befehl „SVN Checkout…“.

Im nun folgenden Dialog müssen wir nun die Adresse unseres Subversion-Repository angeben – dabei lassen wir alle Optionen wie voreingestellt.

Tortoise holt nun alle Ordner und Dateien vom Server ab, so wie sie aktuell im Repository vorliegen.

Da unser Repository nur die von Visual-SVN vorgeschlagene Ordnerstruktur enthält, werden lediglich die Unterverzeichnisse in unserer Arbeitskopie abgelegt – unsere Struktur sieht nun also wie folgt aus:

Diese Struktur hat sich in der Praxis bewährt und wird so auch von den meisten Anwendern verwendet.
branches - hier werden bei Bedarf Abspaltungen aus dem Hauptprojekt fortgeführt
tags - für speziell markierte Versionen/Zustände
trunk - die eigentliche laufende Entwicklung

Einstellungen in OASIS

Im Beispiel verwende ich die bekannte „Nordwind.mdb“, die bei einer normalen Installation von Access von Microsoft mitgeliefert wird.
Dieser Datenbank teilen wir als nächstes mit, wo sich die Quelldateien befinden.

Da wir zuerst nur unseren normalen Entwicklungsast des Repository verwenden möchten, geben wir als Verzeichnis für diese Datenbank den Ordner „trunk“ unserer Arbeitskopie an.

Um direkten Zugriff auf die Tortoise-Funktionen zu erhalten, sollte die Option "Symbolleistenschaltflächen anzeigen" gesetzt sein.

Export der Dateien

Nachdem OASIS wie gewünscht konfiguriert wurde, exportieren wir alle Objekte unserer Datenbank in das Verzeichnis.

Dazu öffnen wir mit OASIS den Exportdialog, markieren mit STRG+A alle Objekte und exportieren diese dann durch einen Klick auf OK.

Übertragen der Änderungen

Um die Quelldateien - die sich ja z.Zt. nur im entsprechenden Ordner unserer Arbeitskopie befinden – nun in das Repository auf dem Webserver zu übertragen, können wir entweder das Kontextmenü im Windows-Explorer verwenden, oder aber den in OASIS angebotenen Menüpunkt „Commit…“.

Im nun erscheinenden Dialog werden uns alle soeben exportierten Dateien aufgelistet und als „non-versioned“ deklariert.
Wir markieren die Checkbox „Select / deselect all“, um alle Dateien zu übertragen.
Jeder Aktion kann und sollte ein individueller und aussagekräftiger Kommentar mitgegeben werden, damit wir später noch wissen, was gemacht wurde.
Nachdem wir den Dialog mit OK geschlossen haben, werden die markierten Dateien in das Repository auf dem Server übertragen – unsere erste Revision ist „eingecheckt“.
Wir können nun nach Belieben an unseren Access-Objekten arbeiten.

Laufende Aktualisierung

Nachdem wir nun z.B. an einem unserer Module einige Änderungen durchgeführt haben, möchten wir diese natürlich auch in das Repository übertragen.
Wir können dazu wieder den Exportdialog von OASIS verwenden und die entsprechenden Objekte (unser geändertes Modul oder weitere) markieren.
Handelt es sich aber wie in diesem Fall nur um ein einzelnes Objekt, ist es schneller und infacher, dieses über das Access-Kontextmenü zu exportieren.
Das funktioniert sowohl imDatenbankfenster (Navigationsbereich in Access 2007), als auch im VBA-Editor.

Der erfolgreiche Export wird durch ein akustisches Signal angezeigt.
Sobald wir der Meinung sind, unsere Änderungen sollten in das Repository übertragen werden, verwenden wir wieder den Befehl „Commit“.

Hier werden uns nur noch die Dateien angezeigt, die seit der letzten Aktualisierung verändert wurden.
Auch hier geben wir wieder einen sinnvollen Kommentar ein und übertragen die Änderungen n das Repository.

Abholen des aktuellen Revisionsstandes

Solange wir allein an einem Projekt arbeiten, reicht das bisher beschriebene Verfahren aus, um unseren Projektfortschritt im Repository zu dokumentieren.
Nebenbei haben wir uns hier auch eine vorzügliche Datensicherung geschaffen.
Interessant wird es, wenn wir nicht allein an einem Projekt arbeiten, sondern die Aufgaben auf mehrere Personen aufgeteilt werden.
Dann benötigen wir (mehr oder weniger regelmäßig) auch den Befehl „Update“, der die im Repository ggf. aktualisierten Inhalte der anderen Teammitglieder abholt und in unsere Arbeitskopie überträgt.

Hier wird uns z.B. mitgeteilt, dass ein anderes Teammitglied weitere Änderungen an nserem zuletzt bearbeiteten Modul durchgeführt hat.
Über den Button „Show log…“ können wir uns dazu die Details und auch den vom jeweiligen Entwickler eingegebenen Kommentar ansehen.

Import in Access

Die geänderten Dateien können wir nun (ähnlich wie beim Export) über den Importdialog von OASIS in unsere Datenbank importieren.
Sind es aber nur einzelne Dateien, genügt wieder ein Klick im Kontextmenü, um das Objekt durch den aktuellen Stand im Arbeitsverzeichnis zu ersetzen.
Auch hier wird der Erfolg des Vorgangs wieder akustisch angezeigt.

Tipp: Auf diese Art und Weise können wir z.B. auch mal eine fehlerhafte Änderung an einem Objekt (Formular, Bericht, Modul etc.) rückgängig machen und auf den aktuellen Zustand im Arbeitsverzeichnis zurückgreifen.

Fortgeschrittene Techniken

Bis hier sind die für die tägliche Arbeit wichtigsten und meistverwendeten Befehle beschrieben.
Weitere Möglichkeiten werden in den folgenden Absätzen beschrieben.

Änderungen rückgängig machen

Auch wenn wir uns in unserer Entwicklung einmal komplett verrannt haben und mit OASIS fehlerhafte Objekte in unser Arbeitsverzeichnis exportiert haben, können wir sehr einfach mit Hilfe des Befehls „Zurücksetzen“ (Revert) auf den aktuellen Stand des Versionsservers zurückgreifen.

Hier werden uns alle Dateien angeboten, die seit der letzten Aktualisierung in unserem Arbeitsverzeichnis verändert wurden.
Wir markieren einfach alle Dateien, die wir durch die Version auf dem Server ersetzen möchten, bestätigen mit OK und importieren diese wieder mit OASIS in unsere Datenbank.

Konkurierende Änderungen

Im Normalfall sollten die Arbeiten innerhalb eines Teams so aufgeteilt sein, dass sich zwei Entwickler nicht in die Quere kommen.
Sollte nun aber der Fall eintreten, dass eine Datei übertragen wird, die ein anderes Teammitglied in der Zwischenzeit ebenfalls geändert und auch „eingecheckt“ hat, weist Tortoise uns auf diesen Umstand hin.

Um diesen Konflikt zu lösen, müssen wir zuerst einmal den aktuellen Stand des Repository mittels „Update“ vom Server abholen.

Dabei werden wir auf den Konflikt hingewiesen und können ihn im einfachsten Fall auch direkt im Dialog lösen.
Dazu klicken wir vor allen anderen Aktionen mit der rechten Maustaste auf den fehlerhaften Eintrag.

Falls wir z.B. wissen, dass unsere Änderungen nicht von Belang sind, können wir hier mit „Resolve conflict using ‚theirs’“ die Änderungen des anderen Entwicklers einfach übernehmen – unsere eigenen Änderungen werden dabei verworfen.
Um hier eine Entscheidung zu vereinfachen, können wir auch den Dialog „Compare with working copy“ zu Rate ziehen.
Mit Hilfe von „Edit conflicts“ können wir aber auch beide Versionen miteinander vergleichen und zeilenweise entscheiden, ob wir:

• unsere Änderungen oder die des anderen Teammitglieds verwenden möchten

oder

• beide Änderungen beibehalten möchten

wobei wir dabei noch entscheiden können, in welcher Reihenfolge einzelne Zeilen übernommen werden.

Merge vs. Locking

Eine grundlegende Frage spaltet im Prinzip die Anwender von Versionskontrollsystemen in zwei Lager:
Verwende ich Sperren, oder nutze ich im Zweifelsfall die Möglichkeiten zum Zusammenführen konkurierender Änderungen?
Diese Frage kann einem Team niemand abnehmen und muss abhängig von den Randbedingungen (Größe des Teams, Erfahrung, Standort etc.) von Fall zu Fall entschieden werden.
Mit Subversion sind jedenfalls beide Wege möglich – über das Kontextmenü lässt sich eine Datei/Verzeichnis mittels „get lock“ auch explizit vor der Veränderung durch andere Teammtglieder schützen.
Erfahrungen zeigen aber, dass dies bei den meisten Projekten nicht notwendig ist.

SVN vs. VSS & Co.

Zum Schluß noch einige Merkmale, die für den Einsatz von SVN sprechen:

• Kostenlos
• Open-Source
• Plattformunabhängig
• Kein Locking erforderlich (aber möglich)
• Große Community
• Viele Erweiterungsmöglichkeiten:
  - Weboberflächen für das Browsen im Repository
  - Integration in viele Bugtracking-Systeme (BugZilla, Mantis, Trac u.v.a.)
  - Integration in viele CMS-Systeme

Bei Fragen oder Anregungen zu diesem Tutorial stehe ich wie immer gerne mit Rat und Tat zur Seite!