Sourceverwaltung und PowerBuilder

1. Sourceverwaltung und PowerBuilder Christoph Menken Power People

2. Warum Versions Kontrolle? • PB Native • SCC Anforderungen • Die SCC API • SCC-Architektur in PB 8/9 • Visual Source Safe • PowerGen • Fragen Fahrplan Sourceverwaltung und PowerBuilder

3. 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 Warum Versionskontrolle? Sourceverwaltung und PowerBuilder

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

5. 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 SCC Anforderungen Sourceverwaltung und PowerBuilder

6. myApp SRC d_ph.srd d_mc.src DOC setup.txt • Projekt • Verzeichnisse und Unterverzeichnisse • Archive • Jede Änderung wird mit einer speziellen Versionsnummer versehen • Viele SCC Tools verwenden “Delta” oder “Reverse Delta” Dateiformate. Die SCC APIInnerhalb der SCC Repository Sourceverwaltung und PowerBuilder

7. Server Konfiguration (Server Configuration) • Projekt (Project) • Sicht (View) • Ordner (Folder) • Archive • Labels • Arbeitsordner (Working Folder) Die SCC APISCC Terminologie Sourceverwaltung und PowerBuilder

8. Revision Labels, applied to specific sets of changed objects Änderungsmarkierungen (Revision Labels), sind bestimmten Mengen geänderter Objekte zugeordnet View Labels, applied to ALL objects associated to the View Sichtmarkierungen (View Labels), sind ALLEN mit der Sicht verbundenen Objekten zugeordnet Datei A Datei B Datei C Datei D Datei E Datei F Die SCC API Source Code Lebenszyklus Sourceverwaltung und PowerBuilder

9. 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 Die SCC API Sourceverwaltung und PowerBuilder

10. 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! Die SCC APIweitere Terminologie Sourceverwaltung und PowerBuilder

11. 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” Die SCC APIPowerbuilder spezifisch Sourceverwaltung und PowerBuilder

12. 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 APIBeispiel „Checkout“ Sourceverwaltung und PowerBuilder

13. 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 APIBeispiel „Checkin“ Sourceverwaltung und PowerBuilder

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

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

16. 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 SCC-ArchitekturKeine gemeinsamen Pibbles im Netz Sourceverwaltung und PowerBuilder

17. 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 SCC-ArchitekturSCC Status nicht in der PBL Sourceverwaltung und PowerBuilder

18. 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 SCC-ArchitekturSccQueryInfo() Sourceverwaltung und PowerBuilder

19. “Ü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 SCC-Architektur Keine “work.pbl” Sourceverwaltung und PowerBuilder

20. SCC-Architektur in PB 8/9Icons der PB 8.0 IDE Sourceverwaltung und PowerBuilder

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

22. 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 SCC-ArchitekturOperationen auf mehreren Objekten Sourceverwaltung und PowerBuilder

23. 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 SCC-ArchitekturVerzeichnis-hierarchien Sourceverwaltung und PowerBuilder

24. 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 SCC-ArchitekturSCC Verbindung als Workspace Eigenschaft Sourceverwaltung und PowerBuilder

25. Neue Verbindungs-Eigenschaften SCC-ArchitekturWorkspace Properties Source Control Tab Sourceverwaltung und PowerBuilder

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

27. 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 SCC-Architektur Target-Wide SCC Operations Sourceverwaltung und PowerBuilder

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

29. 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 SCC-Architektur PBNative als SCC Provider Sourceverwaltung und PowerBuilder

30. Mögliche Visual Diff Tools: • PBDelta • PerforceP4diff.exe • MicrosoftWindiff.exe (Visual Studio Tools) SCC-Architektur Visual Diff Konfiguration unter PBNative Sourceverwaltung und PowerBuilder

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

32. 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. Aufsetzen der SCC Integration in PB8 Sourceverwaltung und PowerBuilder

33. 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 Tips & Hinweise Sourceverwaltung und PowerBuilder

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

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

36. Optimize • Regenerate • Create Exe, PBD‘s, DLL‘s • Build • Export • Source Control Integration PowerGen Sourceverwaltung und PowerBuilder

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