Sourceverwaltung und PowerBuilder

Präsentation zum Thema: "Sourceverwaltung und PowerBuilder"—  Präsentation transkript:

1 Sourceverwaltung und PowerBuilder
Christoph Menken Power People

2 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 Sourceverwaltung und PowerBuilder

3 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 Sourceverwaltung und PowerBuilder

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

5 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, - und Webintegration. SCC Anforderungen PBUGG-Treffen Freiburg Sourceverwaltung und PowerBuilder

6 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 Sourceverwaltung und PowerBuilder

7 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 Sourceverwaltung und PowerBuilder

8 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 Sourceverwaltung und PowerBuilder

9 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 Sourceverwaltung und PowerBuilder

10 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 Sourceverwaltung und PowerBuilder

11 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 Sourceverwaltung und PowerBuilder

12 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 Sourceverwaltung und PowerBuilder

13 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 Sourceverwaltung und PowerBuilder

14 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 Sourceverwaltung und PowerBuilder

15 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 Sourceverwaltung und PowerBuilder

16 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 Sourceverwaltung und PowerBuilder

17 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 Sourceverwaltung und PowerBuilder

18 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 Sourceverwaltung und PowerBuilder

19 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 Sourceverwaltung und PowerBuilder

20 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 Sourceverwaltung und PowerBuilder

21 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 Sourceverwaltung und PowerBuilder

22 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 Sourceverwaltung und PowerBuilder

23 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 Sourceverwaltung und PowerBuilder

24 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 Sourceverwaltung und PowerBuilder

25 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 Sourceverwaltung und PowerBuilder

26 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 Sourceverwaltung und PowerBuilder

27 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 Sourceverwaltung und PowerBuilder

28 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 Sourceverwaltung und PowerBuilder

29 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 Sourceverwaltung und PowerBuilder

30 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 Sourceverwaltung und PowerBuilder

31 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 Sourceverwaltung und PowerBuilder

32 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 Sourceverwaltung und PowerBuilder

33 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 - PBDelta - Es kann jedes 3rd-party “Diff”-Tool über den “Advanced” Dialog in den Workspace Eigenschaften eingebunden werden. Tips & Hinweise PBUGG-Treffen Freiburg Sourceverwaltung und PowerBuilder

34 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 Sourceverwaltung und PowerBuilder

35 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 Sourceverwaltung und PowerBuilder

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

37 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 Berlin fon +49 (0) fax +49 (0) Kontakt PBUGG-Treffen Freiburg Sourceverwaltung und PowerBuilder