Sourceverwaltung und PowerBuilder Christoph Menken Power People

Sourceverwaltung und PowerBuilder Warum Versions Kontrolle? PB Native SCC Anforderungen Die SCC API SCC-Architektur in PB 8/9 Visual Source Safe PowerGen Fragen Zunächst die Frage, wieso brauchen wir eine Versions Kontrolle? Nach einigen Gründen sehen wir uns die Versionsverwaltung mit PB Native an. Da diese einfache Versionsverwaltung, die der Powerbuilder mit liefert einige Wünsche aufwirft, werden wir uns im folgenden Anforderungen an ein „Source Code Control“ – System ansehen. Danach sehen erhalten Sie einen Einblick in die Spezifikation der Microsoft SCC API und deren Integration in PB8 und 9. Anschließend beschäftigen wir uns mit dem Konfigurationsmanagement, in der die Sourceverwaltung ein Bestandteil sein sollte. Zum Schluss erhalten Sie als Beispiel einen Einblick in das Visual Source Safe und den PowerGen. Diese beiden Tools sind Hilfreich bei der Sourceverwaltung und dem Erstellen von Applikationen mit Powerbuilder. Fahrplan PBUGG-Treffen Freiburg 27.10.2003 Sourceverwaltung und PowerBuilder

Warum Versionskontrolle? Mehrere Entwickler arbeiten an den selben Quellen Kompilierte Versionen und ausgelieferte Versionen müssen zum Zweck des Rollback archiviert werden Viele Objekte, Dateien und Pibble sind zu verwalten Zusätzliche Arbeit Versionsmanagement kann in einen Full-Time-Job ausarten Ein Entwickler ist kein Bibliothekar Die Frage „Warum Versionskontrolle?“ ist einfach zu beantworten. Sobald mehrere Entwickler an den selben Quellen arbeiten, kann es zu konkurrierenden Zugriffen kommen. Die einzelnen Builds und die ausgelieferten Versionen müssen archiviert werden, damit notfalls eine fehlerhafte Version zurückgenommen und durch eine intakte vorherige Version ersetzt werden kann. Hierzu sind eine große Anzahl von Objekten, Dateien, Pibble zu verwalten. Dies bedeutet zusätzliche Arbeit in einem Projekt. Je nach Größe des Projektes kann das Versionsmanagement zu einem Full-Time-Job ausarten (Anlegen der Archive, Protokollierung der Versionsstände, Recherche nach einer gültigen Version im Falle eines Rollback, etc.). Entwickler sollen Software designen und konstruieren und nicht die Funktion eines Bibliothekars ausüben, indem Sie das Aus- und Einchecken der Sourcen protokollieren und archivieren. Warum Versionskontrolle? PBUGG-Treffen Freiburg 27.10.2003 Sourceverwaltung und PowerBuilder

Sourceverwaltung und PowerBuilder Verhindert konkurrierende Zugriffe Zentrale Sourcen auf einem Serverlaufwerk Lokale Arbeitskopie Möglichkeit des Offline-Arbeitens PB Native PBUGG-Treffen Freiburg 27.10.2003 Sourceverwaltung und PowerBuilder

Sourceverwaltung und PowerBuilder Sicherer Aufbewahrungsort (Repository) für beliebige digitale Dokumente Versionskontrolle über Objekt/Datei Revision Sperren und Verzweigen (Locking & Branching) Verfolgbarkeit (Traceability) der Änderungen Timetravel (Zeitreise) Integriertes Änderungsmanagement und Fehlernachverfolgung In der Soureverwaltung sollten beliebige digitale Dokumente in einer zentralen Repository gespeichert werden können. Dazu gehören u.a. Quellcode, Dokumentation, Marketing Material, Analysedokumente (Uses Cases, DB-Modell, etc.), Spezifikationen. Die Repository soll sicher sein, so dass nur autorisierte Anwender Zugriff auf die entsprechenden Dokumente haben. Um die Versionen nachvollziehbar zu machen sollte ein verständliches, aussagekräftiges Revisionsnummernschema verwendet werden. Die Objekte sollten in der Zeit der Bearbeitung verschließbar sein, so dass kein konkurrierender, gleichzeitiger Zugriff von Objekten möglich ist. Falls konkurrierende Zugriffe notwendig sind, sollte das System „Branching“ erlauben. Hierdurch können Objekte gleichzeitig durch mehrere Anwender bearbeitet werden, wodurch eine Verzweigung in der Bearbeitungshierarchie entsteht. Alle Änderungen sollten später nachvollzogen werden können. Hierzu ist es wichtig wer, wann an dem Objekt gearbeitet hat. Demnach sollte jede Änderung mit Autor, Datum und Uhrzeit versehen werden. Zusätzlich sind Kommentare, die die durchgeführte Änderung beschreiben für eine spätere Revision hilfreich. Jederzeit sollte ein früherer Stand wieder herstellbar sein. Mit Hilfe von Labeln können eindeutige, aussagekräftige Namen zu einer speziellen Konfiguration zugeordnet werden. Einige SCC-Tools unterstützen zusätzlich den gesamten Software-Entwicklungsprozess durch Fehlerreporting/-tracking, Entwicklungs-Workflow, Email- und Webintegration. SCC Anforderungen PBUGG-Treffen Freiburg 27.10.2003 Sourceverwaltung und PowerBuilder

Die SCC API Innerhalb der SCC Repository d_ph.srd myApp SRC d_mc.src setup.txt DOC Projekt Verzeichnisse und Unterverzeichnisse Archive Jede Änderung wird mit einer speziellen Versionsnummer versehen Viele SCC Tools verwenden “Delta” oder “Reverse Delta” Dateiformate. Es ist wichtig zu verstehen, wie der SCC Provider die Änderungen ablegt und die lokale Arbeitskopie synchronisiert. Einige SCC Provider (ClearCase), verwenden dynamische Sichten und halten die lokale Arbeitskopie immer synchron, wodurch ein SCCDiff() Aufruf zwecklos wird. Die SCC API Innerhalb der SCC Repository PBUGG-Treffen Freiburg 27.10.2003 Sourceverwaltung und PowerBuilder

Die SCC API SCC Terminologie Server Konfiguration (Server Configuration) Projekt (Project) Sicht (View) Ordner (Folder) Archive Labels Arbeitsordner (Working Folder) Server Konfiguration (Server Configuration)– Verknüpfung in eine physikalische Repository Projekt (Project) – Verbunden mit einer Produkt Version (Release) Sicht (View) – Eine Untermenge von Objekten in einem Projekt. Ordner (Folder) – Hilfe um Projekte/Views besser zu organisieren Archive – Aktuell versionisierbare Objekte und Dateien Labels – Namen die spezielle Revision Archive identifizieren Arbeitsordner (Working Folder) – Verzeichnis in dem die Dateien bearbeitet werden. Die SCC API SCC Terminologie PBUGG-Treffen Freiburg 27.10.2003 Sourceverwaltung und PowerBuilder

Die SCC API Source Code Lebenszyklus Datei A Datei B Datei C Datei D Datei E Datei F Revision Labels – Eine Methode, um bestimmte Objektversionen zu speziellen Revisionen oder Erweiterungen zuzuordnen. Hierbei handelt es sich um eine Untermenge von Objekten in einem View. View Labels – Werden ALLEN Objekten in einem View zugeordnet. Analog: In der Geologie – eine Gesteinsschicht oder ein Ablagerungssediment bildet einen feststehenden Zeitpunkt ab, egal, in welcher Höhe es gefunden wird. Also, wenn das SCC Tool “promotion states” unterstützt, kann ein Build Label mit dem entsprechenden Promotion State verbunden werden, so dass hierdurch verschiedene Stati wie z.B. "Produktion“, "Beta“, "QS“, "Entwicklung“, etc. identifiziert werden können. Revision Labels, applied to specific sets of changed objects View Labels, applied to ALL objects associated to the View Änderungsmarkierungen (Revision Labels), sind bestimmten Mengen geänderter Objekte zugeordnet Sichtmarkierungen (View Labels), sind ALLEN mit der Sicht verbundenen Objekten zugeordnet Die SCC API Source Code Lebenszyklus PBUGG-Treffen Freiburg 27.10.2003 Sourceverwaltung und PowerBuilder

Sourceverwaltung und PowerBuilder SCC ist eine Industrie-Standard API die von den meisten Anbietern von Sourceverwaltungssystemen unterstützt wird SCC API unterstützt: Präzise Status Informationen der Repository-Archive Unterverzeichnis in der Änderungshierarchie Operationen um mehrere Objekte mit einer API Anfrage zu bearbeiten Vor der Entwicklung dieser API, war es notwendig, dass jeder IDE Anbieter ein spezielles Interface für jeden gängigen SCC Anbieter hatte. Nun, da die SCC API implementiert wurde, kann PB jedes angebotene SCC Werkzeug integrieren. Die SCC API PBUGG-Treffen Freiburg 27.10.2003 Sourceverwaltung und PowerBuilder

Die SCC API weitere Terminologie Local Project Path: der lokale Projektpfad auf dem lokalen Rechner in dem die PB IDE die exportierten Source Dateien verwaltet. Hier muss der aktuelle „Workspace“ liegen (*.pbw) Dieser Pfad ist für alle „Targets“ gleich SCC Working Folder: Der Arbeitsordner, wo das SCC Werkzeug die Arbeitskopien der entsprechenden Objekte/Dateien ablegt. Das SCC Werkzeug verwendet diesen Ordner wenn dessen Userinterface mit Archiven arbeitet. Jede/r SCC Sicht/Ordner kann einen anderen Arbeitsordner verwenden. ACHTUNG: Dies MUSS NICHT derselbe Pfad sein! 90% der Zeit sollte der SCC Arbeitsordner und der PB lokale Projekt Pfad gleich sein. Wie auch immer, es ist MÖGLICH und manchmal NOTWENDIG den SCC Arbeitsordner zu ändern. Zum Beispiel wenn ein vorheriges Build in einen extra Build-Bereich soll. Die SCC API weitere Terminologie PBUGG-Treffen Freiburg 27.10.2003 Sourceverwaltung und PowerBuilder

Die SCC API Powerbuilder spezifisch EXPORT der Quellen vor SccAdd() “Hinzufügen zur Source Control” SccCheckin() “Einchecken” SccDiff() “Unterscheide vergleichen” IMPORT der Quellen nach SccCheckout() “Auschecken” SccGet() “Hole die letzte Version” SccUncheckout() “Auschecken rückgängig machen” PB muss zuerst die Objektsource in Dateien im lokalen Projektpfad EXPORTIEREN bevor die folgenden Funktionen aufgerufen werden: SccAdd() “Hinzufügen zur Source Control” SccCheckin() “Einchecken” SccDiff() “Unterscheide vergleichen” PB muss die Objektquelldateien aus dem lokalen Projektpfad IMPORTIEREN nachdem folgende Funktionen aufgerufen wurden: SccCheckout() “Auschecken” SccGet() “Hole die letzte Version” SccUncheckout() “Auschecken rückgängig machen” Die SCC API Powerbuilder spezifisch PBUGG-Treffen Freiburg 27.10.2003 Sourceverwaltung und PowerBuilder

Die SCC API Beispiel „Checkout“ PB exportiert Kopien der Objekte als Backup (für ein evtl. Rollback) PB ruft SccCheckout() auf. Das SCC Tool schreibt die letzte Version in den lokalen Projekt Pfad PB ruft SccQueryInfo() auf um sicherzustellen, dass das Objekt erfolgreich ausgecheckt wurde PB importiert die Objekte in die entsprechende Pibble PB aktualisiert den Status Cache und aktualisiert die IDE PB commited die Transaktion & löscht die Backup-Dateien Die SCC API Beispiel „Checkout“ PBUGG-Treffen Freiburg 27.10.2003 Sourceverwaltung und PowerBuilder

Die SCC API Beispiel „Checkin“ PB exportiert die Syntax der einzuchekenden Objekte in den lokalen Projekt Pfad PB ruft SccCheckIn() auf. Das SCC Tool aktualisiert die Revisionshistorie in den Archiven gibt die Datei wieder frei PB ruft SccQueryInfo() um das erfolgreiche Einchecken zu überprüfen PB aktualisiert den Status Cache und aktualisiert die IDE Die SCC API Beispiel „Checkin“ PBUGG-Treffen Freiburg 27.10.2003 Sourceverwaltung und PowerBuilder

SCC-Architektur Änderungen in PB8 SCC Status Information wurden aus der Pibble genommen Beseitigt den Bedarf gemeinsam genutzter Pibbles im Netzwerk Mit SccQueryInfo() können Status Information eingeholt werden Neue Icons in der IDE Es gibt jetzt den “Out-of-Sync” Status Neuer “Offline Mode” SCC Operationen können über gesamte Targets durchgeführt werden Unterstützt Verzeichnis-Hierarchien und Unterprojekte Beseitigt die “work” Pibble SCC-Architektur Änderungen in PB8 PBUGG-Treffen Freiburg 27.10.2003 Sourceverwaltung und PowerBuilder

SCC-Architektur Änderungen in PB8 SCC Verbindung wurde eine Workspace Eigenschaft Unterstützt Source Verwaltung für Web Targets Erlaubt SCC Operationen über gesamte Targets Neuer “CheckView” Dialog Neue PBW, PBT, PBG, und PBC Dateien Ersetzt “Old” PBNative mit einem SCC Anbieter SCC-Architektur Änderungen in PB8 PBUGG-Treffen Freiburg 27.10.2003 Sourceverwaltung und PowerBuilder

SCC-Architektur Keine gemeinsamen Pibbles im Netz Privater Arbeitsbereich für jeden Entwickler Keine Datei-Locking Probleme beim Ausführen oder Debuggen von Applikationen “Offline” arbeiten ist jetzt möglich Reduziert Dateizugriffe im Netz Status Informationen für Objekte eines Arbeitsbereichs werden nun in einer Hash-Tabelle im Speicher gehalten Vor PB 8 musste jeder Anwender einen gemeinsamen Satz von “registrierten Pibble” verwenden, von wo die Objekteaus- und eingecheckt wurden. Dateizugriffsfehler traten oft auf, wenn mehrere Anwender diese Pibbles teilten. PB 8 beseitigt diese registrierten Pibble vollkommen. SCC-Architektur Keine gemeinsamen Pibbles im Netz PBUGG-Treffen Freiburg 27.10.2003 Sourceverwaltung und PowerBuilder

SCC-Architektur SCC Status nicht in der PBL Status Information in der PBL waren unzuverlässig Registrierung von PBL erforderte einen Zugriff auf ein Netzlaufwerk und mussten zwischen den Team Mitgliedern verteilt werde Verursacht Dateizugriffs Probleme beim Starten und Debuggen der Applikation Uneffiziente Dateizugriffe im Netzwerk um Status Information einzuholen „Offline“ Arbeiten erforderte einen privaten Arbeitsbereich auf einem lokalen Laufwerk Status Informationen der Objekte wurden bei PB7 in den registrierten Pibbeln im Netzwerk gehalten. Netzwerkdateizugriffe mussten durchgeführt werden um die Status Informationen der Objekte in der Sourceverwaltung einzuholen. SCC-Architektur SCC Status nicht in der PBL PBUGG-Treffen Freiburg 27.10.2003 Sourceverwaltung und PowerBuilder

SCC-Architektur SccQueryInfo() Ermittelt verlässliche Status Informationen direkt vom SCC Provider Status Cache wird nach Bedarf gefüllt Performance Auswirkungen werden in einem zukünftigen Release adressiert Status Cache wird in einer Hash-Tabelle im Speicher gehalten Sofortzugriff auf Informationen Konfigurierbare Auffrischrate Optionale Eigenschaft findet lokale, „Out-of-Synch“ Objekte sind Stellt serienmäßig den Status Cache beim schließen des Arbeitsbereichs her (.PBC file) Offline Mode verwendet die „.PBC“-Datei für die letzten Status Infos Die Status Information in der Pibble war unzuverlässig. Ein Anwender konnte einfach einen anderen Satz “registrierter Pibble” definieren und von dort auschecken. In diesem Fall zeigt seine registrierte Pibble korrekt den Status „checked out“, aber alle seine Kollegen, die einen anderen Satz registrierter Pibble verwenden würden den tatsächlichen Checkout-Status nicht sehen. SCC-Architektur SccQueryInfo() PBUGG-Treffen Freiburg 27.10.2003 Sourceverwaltung und PowerBuilder

SCC-Architektur Keine “work.pbl” “Überflüssiges” Überbleibsel des alten PBNative Denkmusters Status Informationen werden nicht länger in den Pibblen gehalten Jeder Entwickler hat jetzt seinen eigenen Arbeitsbereich Überflüssig für SCC Operationen Einfaches Ein- und Auschecken Beseitigt 4 Schritte zum erfolgreichen Auschecken Beseitigt 8 Schritte zum erfolgreichen Einchecken Erheblich einfacheres Rollback Die Work-Pibble wird überflüssig, wenn wir die registrierten Pibble beseitigen. Jeder Entwickler verwendet seinen eigenen Satz Eintwicklungs-Pibble auf einem lokalen Laufwerk und alle Objekte werden an Ort und Stelle ausgecheckt. SCC-Architektur Keine “work.pbl” PBUGG-Treffen Freiburg 27.10.2003 Sourceverwaltung und PowerBuilder

SCC-Architektur in PB 8/9 Icons der PB 8.0 IDE Bedeutung + Objekt befindet sich Lokal und nicht in der Sourceverwaltung . Objekt befindet sich in der Source Verwaltung und ist von niemand ausgecheckt Objekt ist vom aktuellen Anwender ausgecheckt Objekt ist von einem anderen Anwender ausgecheckt @ Lokales Objekt ist mit dem Server-Objekt nicht synchron SCC-Architektur in PB 8/9 Icons der PB 8.0 IDE PBUGG-Treffen Freiburg 27.10.2003 Sourceverwaltung und PowerBuilder

SCC-Architektur “Offline” Modus Großartig für Entwickler mit Notebooks Außerordentlich Effizient Erhält Status Information vom Status Cache (.PBC file) welcher beim letzten Verlassen des Arbeitsbereichs gebildet wird Ermöglicht das offline Editieren von ausgecheckten Objekten Verwendet Read-only Attribute für nicht ausgecheckte Objekten SCC-Architektur “Offline” Modus PBUGG-Treffen Freiburg 27.10.2003 Sourceverwaltung und PowerBuilder

SCC-Architektur Operationen auf mehreren Objekten Hinzufügen mehrerer Objekte mit einem SCC API Aufruf Schneller und effizienter “Erweiterte” Attribute auf alle Objekte anwendbar Objekts aus mehreren Pibble in einem Target auschecken In PB 7.0 nicht möglich Kompilation in drei Durchgängen / Import löst wechselseitige Abhängigkeiten auf Wenn der Anwender in PB 8 25 Objekte eincheckt geben wir einen SccCheckin() Auftrag an den Server und übergeben ein Array mit 25 Dateinamen. PB 7 verwendet hingegen 25 SccCheckin() Aufträge mit jeweils einem Dateinamen. Starke Performancesteigerung. SCC-Architektur Operationen auf mehreren Objekten PBUGG-Treffen Freiburg 27.10.2003 Sourceverwaltung und PowerBuilder

SCC-Architektur Verzeichnis-hierarchien Unbedingt Erforderlich für Web Targets Erlaubt PB Entwickler Objekte in Unterverzeichnissen auf der lokalen Workstation und Archiv Laufwerken zu organisieren Logische Anordnung von Objekten Erlaubt Objekte mit gleichen Namen in unterschiedlichen Archivverzeichnissen PB 7 kommuniziert beim Exportieren der Objekte in den lokalen Projektpfad, immer mit dem SCC Provider. Objekte wurden niemals in Unterverzeichnisse des lokalen Projektpfades geschrieben. Bisher konnten wir nur mit einem Verzeichnis im SCC Repository kommunizieren. Web Targets erfordern es, dass Objekte in mehreren Verzeichnisse unter dem lokalen Projektpfad gespeichert und wiederhergestellt werden. Die Zuordnung der SCC Connection zum PB Workspace erlaubt es nun gleichzeitig an mehreren Targets unter Sourcekontrolle zu arbeiten ohne Abmelden und wiederanmelden an die Sourceverwaltung. Dies ist viel effizienter als bisher. SCC-Architektur Verzeichnis-hierarchien PBUGG-Treffen Freiburg 27.10.2003 Sourceverwaltung und PowerBuilder

SCC-Architektur SCC Verbindung als Workspace Eigenschaft In PB 7.0. war die SCC Verbindung eine Eigenschaft der Applikation In PB 8.0 werden Applikationen als Targets betrachtet. Es können mehrere Targets gleichzeitig in einem Workspace bearbeitet werden Die SCC Verbindung kann während des Wechsel zwischen zwei Targets innerhalb eines Workspace gehalten werden Verschiedene Targets können sich Pibble in einem Workspace teilen Die SCC Verbindungsinformationen werden in der Windows Registry gespeichert. Dies erfordert keine .CFG Dateien und PB.INI Einträge mehr HKCU\Software\Sybase\PowerBuilder\8.0\Workspace\workspace_name\SourceControl Die Zuordnung der SCC Connection zum PB Workspace erlaubt es nun gleichzeitig an mehreren Targets unter Sourcekontrolle zu arbeiten ohne Abmelden und wiederanmelden an die Sourceverwaltung. Dies ist viel effizienter als bisher. SCC-Architektur SCC Verbindung als Workspace Eigenschaft PBUGG-Treffen Freiburg 27.10.2003 Sourceverwaltung und PowerBuilder

SCC-Architektur Workspace Properties Source Control Tab Neue Verbindungs- Eigenschaften Work Offline: Eingabeaufforderung, ob die Verbindung zur Sourceverwaltung hergestellt werden soll, oder nicht Delete PB-Generated Object Files: Löscht die PB-Objektdateien von der Platte. Dies spart Speicherplatz auf dem lokalen Laufwerk, bedingt aber einen Performance Verlust. Perform DIFF –Hierdurch kann man sich mehr auf das “Out of Sync” Icon verlassen Refresh rate – Wie oft die Status Informationen erneuert werden SCC-Architektur Workspace Properties Source Control Tab PBUGG-Treffen Freiburg 27.10.2003 Sourceverwaltung und PowerBuilder

SCC-Architektur Web Targets unter Source Control PB 8.0 unterstützt Source Verwaltung für Web Targets PB Targets und Web Targets können zusammen in einem Workspace unter Source Verwaltung existieren Alle Web Target Verzeichnisse müssen im lokalen Projekt Pfad existieren SCC-Architektur Web Targets unter Source Control PBUGG-Treffen Freiburg 27.10.2003 Sourceverwaltung und PowerBuilder

SCC-Architektur Target-Wide SCC Operations Mit PB 8.0 können SCC Operationen für ein gesamtes Target durchgeführt werden Rechter Mausklick auf das Target Icon “Get Latest Version” zur Synchronisation das lokale Target mit dem SCC Provider Auswahl: “Select Multiple Files Contained Within this Target” Der CheckView Dialog selektiert automatisch alle Objekte, die entweder lokal nicht existieren oder nicht synchron sind Kompilation in drei Durchgängen / Import löst wechselseitige Abhängigkeiten auf Die „SELECT ALL“ Schaltfläche kann sehr gefährlich sein… Hierdurch werden ALLE Objekte überschrieben, die ausgecheckt sind und greift ALLE Objekte im Target auf. Dieses wieder importieren kann sehr zeitraubend sein, und ist in der Regel nicht notwendig. SCC-Architektur Target-Wide SCC Operations PBUGG-Treffen Freiburg 27.10.2003 Sourceverwaltung und PowerBuilder

SCC-Architektur SCC-relevante Dateien *.PBW Workspace *.PBT Target *.PBG Objektbeschreibung einer Pibble *.PBC Offline Status Cache *.PRP Used by PBNative Nur PBT und PBG Dateien werden in der Source Verwaltung registriert SCC-Architektur SCC-relevante Dateien PBUGG-Treffen Freiburg 27.10.2003 Sourceverwaltung und PowerBuilder

SCC-Architektur PBNative als SCC Provider Das alte PBNative wurde entsprechend der PB 8.0 SCC Anforderungen ersetzt Das neue PBNative fungiert als SCC Provider Anstelle einer registrierten Pibble wird nun eine Verzeichnishierarchie auf einem Netzlaufwerk verwendet Verwendet *.PRP Dateien im Archivverzeichnis um den „Checkout“ Status zu protokollieren Nur die letzte Revision wird im Archivverzeichnis gespeichert Keine Revisionshistorie SccDiff() kann verwendet werden Es kann jedes 3rd-party “Diff”-Tool über den “Advanced” Dialog in den Workspace Eigenschaften eingebunden werden. SCC-Architektur PBNative als SCC Provider PBUGG-Treffen Freiburg 27.10.2003 Sourceverwaltung und PowerBuilder

SCC-Architektur Visual Diff Konfiguration unter PBNative Mögliche Visual Diff Tools: PBDelta Perforce P4diff.exe Microsoft Windiff.exe (Visual Studio Tools) SCC-Architektur Visual Diff Konfiguration unter PBNative PBUGG-Treffen Freiburg 27.10.2003 Sourceverwaltung und PowerBuilder

Verzeichnis-hierarchie Alle Targets eines Workspace, die unter Sourceverwaltung sind, müssen auf dem selben Laufwerk bleiben Am Besten legt man den Workspace (*.PBW) in den lokalen Projekt Pfad. Alle Targets (*.PBT) und Objekte die zu den entsprechenden Targets gehören sollten in Unterverzeichnissen des lokalen Projekt Pfads liegen. Verzeichnis-hierarchie PBUGG-Treffen Freiburg 27.10.2003 Sourceverwaltung und PowerBuilder

Aufsetzen der SCC Integration in PB8 Alle Targets unter Sourceverwaltung in einem Workspace müssen auf dem gleichen Laufwerk liegen. Der Workspace (*.PBW) muss im lokalen Projektpfad liegen. Alle Targets (*.PBT) und Objekte die mit jedem Target verbunden sind sollten in Unterverzeichnissen des lokalen Projekt Pfads liegen. Die PB Objekte werden zunächst von einer Workstation registriert und dann wird die komplette Verzeichnisstruktur auf jede weitere Maschine kopiert. Für Web Targets wird der “File > New > Target > Source Controlled Web Target” Assistent verwendet. Es kann jedes 3rd-party “Diff”-Tool über den “Advanced” Dialog in den Workspace Eigenschaften eingebunden werden. Aufsetzen der SCC Integration in PB8 PBUGG-Treffen Freiburg 27.10.2003 Sourceverwaltung und PowerBuilder

Sourceverwaltung und PowerBuilder Wenn Speicherplatz kein Problem ist, sollte “Delete PowerBuilder-generated Object Files” nicht aktiviert sein “Perform DIFF on status update” wird schneller ausgeführt Das SCC Tool meldet nicht den Objekt Status “Missing” Nicht die “Select All”-Schaltfläche im “Get Latest Version”-Dialog verwenden Einige wichtige 3rd-party Werkzeuge: PowerGen - www.ecrane.com PBDelta - www.pbdr.com Es kann jedes 3rd-party “Diff”-Tool über den “Advanced” Dialog in den Workspace Eigenschaften eingebunden werden. Tips & Hinweise PBUGG-Treffen Freiburg 27.10.2003 Sourceverwaltung und PowerBuilder

Sourceverwaltung und PowerBuilder SCC Operationen können auf Pibble Ebene durchgeführt werden Abfrage „… exists in the local project path. Press OK to overwrite …“ kann unterdrückt werden Erweiterter „Checklist“-Dialog Erweiterte SCC Historie Erweiterte Status Ermittlung Erweiterte PBNative Konfiguration Erweiterung des List View im Library Painter 3 SCC Protokollierungslevel Bisher konnten SCC Operationen nur auf einzelne Objekte, oder ein komplettes Target durchgeführt werden. In PB9 können diese Operationen nun auch auf Pibble Basis durchgeführt werden. Um die Objekte zu vergleichen muss PB diese in den lokalen Projektpfad exportieren. Hier kann es vorkommen, dass diese Objekte bereits mit Schreibschutz vorhanden sind. Hier erscheint in PB8 bei jedem einzelnen Objekt die Abfrage, ob das Objekt überschrieben werden kann. In PB9 kann diese Abfrage unterdrückt werden. Der „Checklist“-Dialog ist nun größer und kann resized werden. Es ist nun möglich, sofern der SCC Provider dies unterstützt, ältere Versionen eines Objektes zurückzuholen. Bei der Verwendung von PBNative gibt es nun auch die „Show History“-Funktion. Diese zeigt den lokalen Dateinamen, den aktuellen Status lt. SCC Verwaltung, die Versionsnummer des aktuellen Objekts und den letzten Check-In Status an. Der Status kann nun mithilfe der rechten Maustaste refreshed werden. Dies war bisher nur über das Menü möglich. In großen Projekten dauert es sehr lange, die aktuellen Statusinformationen vom SCC Provider zu holen. Deshalb wurde diese in PB9 in einen extra Thread gepackt, so dass gleichzeitig an den Objekten gearbeitet werden kann, als wäre man im Offline Modus. Während der zweite Thread die Infos aus der Sourceverwaltung holt wird im Titel des Library Painters der Status „Initialization…“ angezeigt. In den PBNative Files (*.prp) wird nun eine Versionsnummer gespeichert. Diese Versionsnummer wird verwendet um den „Out-of-Synch“ Status zu ermitteln. Dies ist eine erhebliche Performance Steigerung, da nicht mehr die kompletten Files geprüft werden. “Enclose file names in double quotes” … Das “Visual Diff”-Tool unterstützt keine Leerzeichen in Dateinamen. “Refer to local PBL entry as argument #1” … Das “Visual Diff”-Tool soll das Repository Objekt nicht als erste Datei zum Vergleichen nehmen. “Generate short (8.3) file names” … Das “Visual Diff”-Tool kann keine langen Dateinamen verwenden. “Generate an extra space prior to file arguments” … Das “Visual Diff”-Tool benötigt ein extra Leerzeichen zwischen den Argumenten. Dies wurde aus Kompatibilitätsgründen eingebaut, da PB8 ein extra Leerzeichen zwischen den Argumenten verwendete. Im Library Painter wird nun die Versionsnummer des Objektes angezeigt. Unter Design > Options kann diese Option („SCC Version Number“) gesteuert werden. Die Versionsnummer wird in den Ziel-Pibbles (*.pbl) und im Cache (*.pbc) gespeichert. Dargestellt wird die Versionsnummer aus der lokalen Pibble. Bei Sourceverwaltungssysteme die SccQueryInfoEx() unterstüzen kann die Versionsnummer lokal in den Objekt Eigenschaften geändert werden. Hierzu muss aber eine Verbindung zum SCC-System bestehen. In PB9 gibt es 3 mögliche Protokollierungslevel. Als Standard ist Level 1 voreingestellt. Wenn Fehler Auftreten fügt Level 2 zusätzliche Diagnose-Informationen hinzu. Metadate und Status Cache Details werden bei einigen SCC Funktionen in Level 3 hinzugefügt. PB9 Erweiterungen PBUGG-Treffen Freiburg 27.10.2003 Sourceverwaltung und PowerBuilder

Sourceverwaltung und PowerBuilder Volle Unterstützung der SCC API Problemlose Integration in PB8/9 Userverwaltung mit unterschiedlichen Rechtestufen Objectsharing zwischen verschiedenen Projekten Labeling, VisualDiff, History Visual Source Safe PBUGG-Treffen Freiburg 27.10.2003 Sourceverwaltung und PowerBuilder

Sourceverwaltung und PowerBuilder Optimize Regenerate Create Exe, PBD‘s, DLL‘s Build Export Source Control Integration PowerGen PBUGG-Treffen Freiburg 27.10.2003 Sourceverwaltung und PowerBuilder

Sourceverwaltung und PowerBuilder Sind noch Fragen offen? Bei Rückfragen oder Anregungen bitte an: Christoph Menken Power People Inh. Ludwin Feiten Am Borsigturm 50 D-13507 Berlin fon +49 (0)30 43032350 fax +49 (0)30 43032355 http://www.powerpeople.de mailto:christoph.menken@powerpeople.de Kontakt PBUGG-Treffen Freiburg 27.10.2003 Sourceverwaltung und PowerBuilder