In dieser Session zeige ich Ihnen einige neue Features von Visual FoxPro 5.0, die die gemeinsame Arbeit an Projekten erleichtern. Einen großen Teil der Session werden wir verwenden, um die Zusammenarbeit von VFP und Source Code Control Programmen (speziell Microsoft Visual SourceSafe) zu erklären.
Desweiteren werde ich Ihnen einige Hinweise zur Arbeitsumgebung geben und auch auf den in Teams angebrachten Programmierstil eingehen.
Team-Development ist zunächst einmal einfach die gemeinsame Arbeit von mehreren Leuten an einem Projekt. Die Notwendigkeit, mit mehreren Leuten an einem Projekt zu arbeiten, ergibt sich daraus, daß Projekte mit Visual FoxPro größer sein können als die Aufgaben, die in der Vergangenheit mit FoxPro 2.x möglich waren. Die Verwendung von Klassenbibliotheken, Datenbankcontainern, Remote-Views, das Erstellen von OLE-Servern mit VFP etc. eröffnet Märkte, die bisher nicht so ohne weiteres zu erreichen waren.
Typisch dafür ist, daß das Ausnutzen aller dieser Features nicht mehr von einem einzelnen Entwickler geleistet werden kann. Viele der einzelnen Bereiche erfordern eine intensive Einarbeitung. Wenn man die Zeiten für diese Einarbeitungen zusammenzählt, kommt man leicht auf eine Stundenzahl, die einem Mitarbeiter für ein Jahr zu tun gibt.
Um überhaupt noch produktiv zu sein, muß man also die Einarbeitung in diese Themen auf mehrere Mitarbeiter verteilen, damit diese in ihrer restlichen Zeit auch noch an der eigentlichen Implementation arbeiten können. Damit diese gemeinsame Arbeit aber möglich wird und reibungslos funktioniert, muß man einige Vorkehrungen für die Arbeitsumgebung schaffen.
Visual FoxPro ist als gemeinsame Basis für die Zusammenarbeit von Spezialisten hervorragend geeignet. Es unterstützt alle oben genannten Bereiche direkt und erleichtert die Kommunikation zwischen den Spezialisten über die eigene mächtige Programmiersprache.
Team-Development in VFP beinhaltet in der Regel die Bevorratung der Sourcecodes auf einem Netzlaufwerk. Da sich Dateien wie Formulardateien oder Klassenbibliotheken aber nicht shared öffnen lassen, muß man andere Mechanismen zur gemeinsamen Arbeit an diesen Dateien finden.
Die Dateien, die von den Entwicklern bearbeitet werden müssen, müssen also sich in exklusivem Zugriff befinden, trotzdem aber für alle Entwickler im Bedarf greifbar sein. Dies ist mit den normalen Mitteln des Betriebssystems nicht mehr zu leisten.
Die Lösung für dieses Zugriffsproblem bietet ein Source Code Control Programm. Ein SCC bietet im Prinzip eine Datenbank zur Verwaltung aller Quelldateien. Alle in einem Projekt erstellten Quelltexte können in dieser Datenbank abgelegt werden.
Sind die Dateien in der SCC-Datenbank eingetragen, können sie von den Benutzern der Datenbank ein- oder ausgecheckt werden. Das Auschecken legt eine Kopie des aktuellen Inhalts der Datenbank im Arbeitsverzeichnis des Entwicklers an. Dieser kann dann die Kopie bearbeiten. Die Kopie in der Datenbank bleibt auf dem Stand, der vor dem Auschecken vorlag. Er ist für die anderen Entwickler weiterhin lesbar.
Nach Abschluß der Bearbeitung wird die Datei wieder eingecheckt und kann dann von einem anderen Entwickler ausgecheckt und bearbeitet werden.
Bei den Eincheckvorgängen werden im SCC-Programm aber nicht Kopien der kompletten Dateien abgelegt, sondern nur die Änderungen zwischen den einzelnen Versionen. Dieser Mechanismus des SCC-Programms bietet natürlich den Ansatz, um eine erweiterte Kontrolle über das Projekt zu gewinnen. SCC-Programme lassen z.B. das Einfrieren von Versionen zu, auf die man jederzeit wieder zurückgreifen kann.
Dadurch, daß nur die Änderungen zwischen den Versionen gespeichert werden, lassen sich alle Änderungen, die von den Entwicklern gemacht wurden, nachverfolgen und auflisten.
Ebenfalls läßt sich eine Analyse der Unterschiede zwischen zwei Versionen machen und die Historie zu einzelnen Dateien ausgeben.
Source Code Control Programme, die Sie mit Visual FoxPro einsetzen wollen, müssen das Microsoft Common Source Code Control API unterstützen. Dies ist die Schnittstelle, die VFP nutzt, um die Features der Sourcecontrol zu nutzen. Programme, die verfügbar sind, und über dieses API verfügen, sind Microsoft Visual SourceSafe (Version 4.0 oder höher) oder der Intersolv PVCS Version Manager (Version 5.2.10 oder höher).
Bei der Installation von SCC-Programmen tragen sich diese selbst in der Registry ein.
SCC-Programme sind Client/Server-Anwendungen. Sie bestehen normalerweise aus einer Datenbank, die auf dem Server liegt und Clients, die darauf zugreifen. Die Datenbank auf dem Server muß für die Benutzung durch die Clients (sprich: die Entwickler) eingerichtet werden. Dazu gibt es Administrationsprogramme, die das Einrichten von neuen Benutzern und die Erteilung von Zugriffsrechten und Paßwörtern zulassen.
Auf jedem Entwicklerrechner muß der entsprechende Client installiert werden.
In dieser Session werde ich auf die Arbeit mit Microsoft Visual SourceSafe (VSS) eingehen, die Features von PVCS sind im Prinzip aber die gleichen und die Optionen, die VFP als Front-End für die SCC bietet, sind identisch.
VSS wird einmal auf dem Server installiert. Es legt dort eine Datenbank an, in die die Projekte später eingetragen werden. Von dort muß es per NetSetup auf die Arbeitsstationen installiert werden.
Die Integration der SourceCode-Control-Programme in VFP geschieht ausschließlich über den Projektmanager.
Dieser handhabt alle Vorgänge, die für das vollständige Ein- und Auschecken notwendig sind. Dabei werden sowohl die Hauptdateien (.SCX, .VCX, .DBF) behandelt, als auch die impliziten Dateien (.SCT, .VCT, .CDX und .FPT). Beim Ein- oder Auschecken braucht man sich also nicht mehr um diese Dateien zu kümmern.
Um ein Projekt unter SourceCode-Control zu stellen, müssen die entsprechenden Optionen im Tools-Optionen-Projects-Dialog eingestellt werden.
In diesem Dialog werden in dem Popup „Active Source Control Provider“ alle SCC-Programme, die installiert wurden, angezeigt. Mit Auswahl eines der eingetragenen Provider wird VFP für die Anbindung von Projekten an diesen Client vorbereitet. Es werden einige Menüpunkte eingefügt, die den Aufruf von SCC-Funktionalität ermöglichen. Mit Hilfe der Einstellungen unterhalb des Popups kann man das Verhalten von VFP beim Erstellen oder Modifizieren von Dateien aus einem Projekt beeinflussen:
In Source Code Control Programmen können alle Arten von Dateien verwaltet werden. Man kann also ASCII- und Binärdateien in das Repository einchecken. Beim Einchecken von geänderten Dateien werden die Dateien vom SCC-Programm untersucht und lediglich die Änderungen in Differenzdateien abgelegt.
Source Code Control Programme können ihre volle Leistungsfähigkeit jedoch nur bei ASCII-Dateien entfalten. Features wie die Änderungskontrolle, Differenzanalyse und Änderungshistorie werden von SCC-Programmen sehr elegant erledigt, wenn es sich um Dateien handelt, die als normaler Text an die Source Code Control übergeben werden. Hier lassen sich die Änderungen zwischen den Versionen sehr gut lesen und ausgeben. Visual FoxPro bietet deshalb ein Programm an, das die Konvertierung von VFP-Dateien in ASCII-Dateien und zurück übernimmt. Das Programm wird in den Optionseinstellungen in der Textbox „Text generation“ angegeben. Die Vorgabe für diesen Eintrag ist „SCCTEXT.PRG“. Das Programm liegt im Quelltext im VFP-Installationsverzeichnis vor.
Die ASCII-Dateien, die dieses Programm generiert, haben folgende Dateiendungen:
Bei allen anderen Dateien wird keine Wandlung vorgenommen.
Dateien, die in der Source Code Control Datenbank verwaltet werden, werden im Projektmanager von VFP mit einem Symbol markiert. Diese Symbole zeigen den Status der Projektdateien an. Es werden folgende Stati symbolisiert:
Bei Verwendung von Visual SourceSafe werden die Symbole für „eingecheckt ohne Konflikte“ und „Konflikte beim Einchecken“ nicht angezeigt, da VSS sofort eine Fehlermeldung erzeugt und auffordert, den Konflikt aufzulösen.
Visual FoxPro Projekte lassen sich auch lokal ohne Source Code Control anlegen und dann zu einem späteren Zeitpunkt einchecken. Der dort ausgeführte Vorgang entspricht dem, was VFP auch tut, wenn man die einzelnen Dateien zu einem unter SCC stehenden Projekt zufügt, nur daß dann alle ASCII-Dateien auf einmal erzeugt und die Dateien des Projektes eingecheckt werden.
Die Projektdateien selbst (.PJX und .PJT) werden nicht in die Source Code Control Datenbank eingecheckt. Statt dessen wird eine ASCII-Datei mit der Erweiterung .PJM erstellt. Nur diese wird ein- oder ausgecheckt.
Ist ein Projekt komplett in der SCC-Datenbank, kann man es mit Hilfe des Menüpunktes „Join Source Control Project ...“ (Menüpunkt „File“) für sich bearbeitbar machen. Bei diesem Vorgang wird aus der .PJM-Datei in der Datenbank ein VFP-Projekt erstellt. Von allen Dateien in der Datenbank werden lokale Kopien erstellt. Die Dateien werden jedoch nicht ausgecheckt und sind schreibgeschützt.
Microsoft Visual SourceSafe hat ein paar Besonderheiten: es verwaltet alle eingecheckten Dateien (bzw. deren Differenzen) als eigene Dateien in Unterverzeichnissen auf dem Datenträger des Servers. Diese Dateien sind nicht bearbeitbar. Sie werden wie Datenbankeinträge gehandhabt und sind über Hash-Tabellen organisiert.
Sie sind in der Größe auf 64 MB begrenzt, daher sollte man keine großen Tabellen in die Source Code Control übernehmen. Die Dateien, ihre Position oder ihre Namen dürfen auf keinen Fall verändert werden, da VSS die Zusammenhänge zwischen den einzelnen Versionen und Projektdateien dann nicht mehr korrekt herstellen kann.
VSS ist (anders als der Name vielleicht suggeriert) keine Versicherung gegen Grobe Fehler oder Böswilligkeit. Es ist lediglich eine Hilfe, den Entwicklungsprozeß mit mehreren Entwicklern durchzuführen und die Änderungen, die diese machen, nachzuhalten.