Kapitel 2 Software Configuration Management

Transkript

1 Vorlesung Softwaretechnologie Wintersemester 2011/12 R O O T S Kapitel 2 Software Configuration Management Stand: 17. Oktober 2011

2 Herausforderungen während der Softwareentwicklung Viele Anforderungen Viele Änderungen Viele Versionen Koordination erforderlich! Viele Projekte Viele Arbeitsumgebungen Viele Entwickler Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 2-2 R O O T S

3 Warum Software Configuration Management? Problem Software-Entwicklung ist nicht linear Man macht Programmierfehler Man trifft falsche Entwurfsentscheidungen Software-Entwicklung ist Teamarbeit Sie und andere arbeiten parallel... auf vielen verschiedenen Dateien Verwaltung verschiedener Versionen Kunde erhält stabile Version, während Entwicklung weitergeht Fehlerkorrekturen müssen in alle Versionen integriert werden Verschiedene Kunden erhalten verschiedene Varianten des Produkts Sie möchten wissen, was Sie wann warum getan haben zu alter Version zurückgehen wissen, wer was wann warum getan hat Änderungen gemeinsam nutzen parallele Entwicklung und Integration kontrollieren Varianten kontrollieren Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 2-3 R O O T S

4 SCM: Das Fundament des Entwicklungsprozesses Analyse Entwurf Implementierung Test Wartung Software Configuration Management (SCM) Sammeln und Verwalten von Informationen um Software zu erzeugen, zu warten und zu erweitern. Quellcode Binärcode Build Skripte Konfigurationen Bitmaps & JPEGs HTML/XML Dateien CGI, Javascript CSS Anforderungen Entwürfe Test Skripte Dokumentation

5 SCM Funktionalitäten Verwaltet alle Komponenten eines Projekts in einem Repository Keine redundanten Kopien Sicher Macht Unterschiede zwischen Versionen sichtbar Was hat sich verglichen mit der gestrigen Version verändert? Erlaubt Änderungen zu identifizieren, auszuwerten, zu diskutieren (!) und sie schließlich anzunehmen oder zu verwerfen. Verwaltet Metadaten: Wer hat was, wann, warum und wo getan? Wer hat was in Klasse X geändert? Warum hat er es verändert? Ermöglicht die Wiederherstellung voriger Zustände Vollständig oder selektiv Erlaubt die Definition von Referenzversionen (Tags) Release (Veröffentlichte Version) Milestone (interne Version, Demo beim Kunden, ) Wichtiger Zwischenstand (fehlerfrei getestete Version, Stand vor )

6 SCM Aktivitäten Configuration item identification Bestimmung der per SCM zu verwaltenden Artefakte Branch management Verwaltung verschiedener Versionen, die später integriert werden sollen Variant management Verwaltung von Versionen die nebeneinander existieren sollen Change management Erfassung, Genemigung und Nachverfolgung von Änderungswünschen Promotion Erzeugung von Versionen für andere Entwickler Release Erzeugung von Versionen für Kunden bzw. Benutzer Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 2-6 R O O T S

7 SCM Grundbegriffe Arbeitskopie Unter Kontrolle eines Programmierers Nur für ihn sichtbar Promotion Repository Zentrales Verzeichnis aller promoteten Versionen Von allen Teammitgliedern benutzt Zentrales Archiv Release Produkt Externe, veröffentlichte Version Foo 95 Foo 98

8 Kapitel 2: Software Configuration Management Grundlegende Ansätze Vault Model Standard Repository Virtual File System

9 Arbeitsumgebung und Repository Arbeitsumgebung ( Sandbox ) Enthält nur die aktuell relevante Version eines jeden Artefaktes aus dem Repository die Aktuellste die letzte Funktionierende... Repository Enthält alle Versionen (incl. branches ) eines jeden Artefaktes, das unter SCM- Kontrolle stehen foo.c src foo.h src foo.c foo.h

10 Allgemeines Szenario Entwicklungswerkzeuge / Entwickler Arbeitsumgebung SCM-Tools Repository Frage: Wie interagieren obige Beteiligte? Muss der Entwickler selbst seine Arbeitsumgebungen verwalten oder kann das ein SCM-Tool (größtenteils) automatisch? Ist immer eine lokale Kopie in einer Arbeitsumgebung erforderlich oder können Entwicklungswerkzeuge direkt auf das Repository zugreifen?

11 SCM-Ansätze: Vault Model Entwicklungswerkzeuge / Entwickler Arbeitsumgebung Repository SCM-Tools Idee Dateien kopieren: Arbeitsumgebung Repository Probleme Evtl. viele private Kopien in Arbeitsumgebungen außerhalb des Repository Entwickler arbeitet evtl. auf veralteten Dateien Möglicher Datenverlust durch gleichzeitige oder abgebrochene Updates Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 2-11 R O O T S

12 SCM-Ansätze: "Standard Repository API" Entwicklungs-Werkzeuge API... / Entwickler Repository Dateien in Arbeitsumgebung ( sandbox ) Idee Alle Entwicklungswerkzeuge greifen direkt auf das Repository zu, über eine standardisierte Schnittstelle Problem Alle Werkzeuge müssen angepasst werden -- bei jeder Änderung des Standards!

13 SCM-Ansätze: "Virtual File System" (VFS) Entwicklungs-Werkzeuge... Entwickler Idee Abfangen von I/O-Operationen des Betriebssystems (open, read, write) und Umleiten zum Repository Vorteile Transparenz, da das Repository als normaler Verzeichnisbaum erscheint... Arbeitsumgebung nahtlose Integration bestehender Standardsoftware Benutzer kann wie gewohnt arbeiten... /... Repository Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 2-13 R O O T S

14 Verbreitete SCM-Tools die obige Ansätze umsetzen CVS (simpel, kostenlos) Repository = Dateisystem Versionierung von Dateien Hauptsächlich Textdateien, Binärdateien nur eingeschränkt SVN (besser, kostenlos) Repository = Datenbank Transaktionsunterstützung Versionierung von Dateien und Ordnern Umbenennungen Text und Binärdatein Komfortable graphische Benutzeroberflächen mächtiger ClearCase (high-end, kommerziell) Virtuelles Dateisystem basierend auf Datenbank Alle Eigenschaften von SVN plus... Dynamische Sichten auf Repository Derived Object Sharing Multiple Server, Replikation Prozessmodelierung Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 2-14 R O O T S

15 Kapitel 2: Software Configuration Management Arbeiten mit SVN (und CVS) Check-in und Check-out Commit und Update Synchronisierung Konfliktbeurteilung durch Dateivergleich Manuelle Konfliktauflösung

16 CVS und SVN: Vault Model CVS / SVN Arbeitskopie Entwicklungswerkzeuge Entwicklungswerkzeuge CVS / SVN Repository Prinzip Arbeitskopie Ein zentrales Sammelbecken ( Repository ) aller relevanter Dateien Nur offizielle Versionen Viele private Arbeitsumgebungen ( Sandbox ) mit Kopien von Dateien Auch temporäre, inkonsistente, unfertige,... Versionen Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 2-16 R O O T S

17 CVS und SVN: Checkin und Checkout CVS / SVN Arbeitskopie Entwicklungswerkzeuge Entwicklungswerkzeuge Checkout CVS (Projekt) / SVN Repository Checkin Arbeitskopie Fügt Projekt dem Repository hinzu Checkout Erstellt eine Arbeitskopie des Projekts vom Repository Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 2-17 R O O T S

18 CVS und SVN: Commit und Update CVS Commit / SVN (Dateien) Arbeitskopie Entwicklungswerkzeuge Entwicklungswerkzeuge Update CVS / SVN (Dateien) Repository Commit Arbeitskopie Transferiert vom Programmierer geänderte Dateien in das Repository Update Transferiert geänderte Dateien vom Repository in die Arbeitskopie Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 2-18 R O O T S

19 Check-In: Projekt unter Versionskontrolle stellen Ausgangssituation Ein Repository existiert Ein Projekt existiert, wird aber noch nicht gemeinsam genutzt. Check-In / Sharing / Promotion des Projektes Das Projekt wird dem Repository hinzugefügt Es ist nun für alle Entwickler verfügbar die Zugriff auf das Repository haben Projekt X Check-In / Sharing Repository Projekt X Entwickler swt2011/gruppe/xx Repository root Projekt Pfad Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 2-19 R O O T S

20 Check-Out: Initialer Projektdownload Check-out eines Projektes Entwickler bekommen eine lokale Arbeitskopie Von jetzt an können sie an dem Projekt arbeiten Auschecken wird nur einmal pro Projekt gemacht! Neue Version aus Repository holen siehe Update Arbeitskopie Entwickler A Projekt X Check out Repository Entwickler B Projekt X Arbeitskopie Projekt X Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 2-20 R O O T S

21 Check-Out: Initialer Projektdownload Entwickler bekommt eine lokale Arbeitskopie eines Projektes Auschecken wird nur einmal pro Projekt gemacht! Neue Version aus Repository holen siehe Update Arbeitskopie von Entwickler A Projekt im Repository Arbeitskopie von Entwickler B Check Out Check Out t 0 t 1

22 Commit: Änderungen in das Repository übertragen Ausgangslage: Entwickler A hat seine Arbeitskopie geändert Commit Er fügt seine Änderungen dem Repository hinzu Mit einem Commit Kommentar teilt er dem Team mit was er warum geändert hat: NullPointer-Exception behoben, die auftrat wenn... Arbeitskopie von Entwickler A Projekt im Repository Arbeitskopie von Entwickler B Check Out Check Out Commit t 0 t 1 t 2

23 Update: Neueste Änderungen vom Repository übernehmen Ausgangslage: Repository hat sich geändert Entwickler B ist sich sicher(!), dass er die Änderungen übernehmen will Update B aktualisiert seine Arbeitskopie mit dem aktuellen Zustand des Repository Problem Bei Konflikten, wird automatisch ein merge durchgeführt evtl. unerwünscht Besser: Zuerst Synchronize benutzen und selbst entscheiden! Arbeitskopie von Entwickler A Projekt im Repository Arbeitskopie von Entwickler B Check Out Commit / Update Check Out Update / Update t 0 t 1 t 2 t 3 Konflikt?

24 Synchronisation: Versionsvergleich Vergleich des Projektes in Arbeitskopie mit Repository bezogen auf Stand beim letzten Abgleich (check-in / commit / check-out / update) Automatisierter Vergleich aller Dateien im Projekt Automatisierter Vergleich einzelner Dateiinhalte Der Entwickler entscheidet selbst was aktuell ist... und führt Updates oder Commits explizit durch (eventuell selektiv) Arbeitskopie von Entwickler A Projekt im Repository Arbeitskopie von Entwickler B Check Out / Update Check Out t 0 / Update Commit Update Gemeinsame Bezugsversion t 1 t 2 t 3 Konflikt?

25 Synchronize View : Gesamtübersicht Automatisierte Gesamtübersicht Vergleich auf Projektebene: Alle Dateien des Projektes (oder des selektierten Ordners) werden verglichen Zeigt pro Datei ein- und ausgehende Änderungen sowie Konflikte durch entsprechende Symbole Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 2-25 R O O T S

26 Symbole im Synchronize View Ausgehende Änderung (lokale Änderung) + - Lokale Datei ist neuer als ihre Version im Repository Überschreibe Version im Repository mit lokaler Version Neue lokale Datei existiert nicht im Repository Füge Datei zum Repository hinzu Datei aus Repository wurde lokal gelöscht Datei aus (nächster Version in) dem Repository löschen Eingehende Änderung ( Änderung im Repository) + - Datei im Repository ist neuer als ihre lokale Version Überschreibe lokale Kopie mit der aus dem Repository Neue Datei aus Repository existiert nicht lokal Füge die Datei der lokalen Arbeitskopie hinzu Lokale Datei wurde im Repository gelöscht Lösche die Datei aus der lokalen Arbeitskopie Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 2-26 R O O T S

27 Bedeutung der Symbole im Synchronize View (Fortsezung) Die vorherige Folie stellt die Fälle dar, wenn eine Datei gegenüber dem Stand des letzten Abgleichs mit dem Repository nur auf einer Seite verändert wurde Änderung nur lokal Übernahme ins Repository (ausgehende Änderung) Änderung nur in Repository Übernahme in lokale Kopie (eingehende Änderung) Wenn eine Datei auf beiden Seiten neuer als der Stand beim letzten Abgleich ist, wird ein Konflikt gemeldet: Dateiinhalt wurde lokal und im Repository verändert Manuelle Konfliktlösung notwendig Konflikt + Lokale veränderte Datei wurde im Repository gelöscht Manuelle Konfliktlösung notwendig Lokale gelöschte Datei wurde im Repository verändert Manuelle Konfliktlösung notwendig Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 2-27 R O O T S

28 Synchronisieren: Konfliktauflösung Konfliktauflösung erfordert Inhaltsvergleich der Dateien Angezeigt in Side-by-side View / Compare Editor von Eclipse Zeigt Versionsvergleich von Dateien ( diff ) übersichtlich an Beginne Detailvergleich durch Doppelklick auf die entsprechende Datei Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 2-28 R O O T S

29 Synchronisieren: Inhaltsvergleich im Compare Fenster SVN- / CVS-Plugin für Eclipse hilft beim Versionsvergleich Compare View Die lokale Arbeitskopie wird mit der Repository Version verglichen Hier ein Fall ohne Konflikte: nur ausgehende Änderung Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 2-29 R O O T S

30 Synchronisieren: Inhaltsvergleich im Compare Editor Fenster Hier die Anzeige eines Konfliktes Bei Bedarf kann auch die gemeinsame Bezugsversion angezeigt werden ( Show Ancestor Pane ). So kann man selbst entscheiden, welches die relevante Änderung ist Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 2-30 R O O T S

31 3-Wege-Konfliktauflösung mit Hilfe der Common Ancestor Pane Anhand des gemeinsamen Vorfahren feststellen was sich geändert hat Die Änderung übernehmen gemeinsamer Vorfahre Version A... x= x= x= x=1... Version B abgeglichene Version (nach merge ) Mit SVN ist dies ein manueller Prozess: Sie selbst entscheiden für jede Datei mit Konflikten für jeden Konflikt in der Datei Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 2-31 R O O T S

32 Beispiel: Common Ancestor Pane (1) Szenario: Gemeinsam eine Ausarbeitung / Veröffentlichung schreiben Konflikte in Datei evaluation.lyx Frage: Welcher Stand ist der neueste? Erster Schritt: Show Ancestor Pane Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 2-32 R O O T S

33 Beispiel: Common Ancestor Pane (2) Antwort: Keiner Hier wurde tatsächlich an der gleichen Stelle parallel geändert! Absprache mit dem Kollegen / Co-Author erforderlich! Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 2-33 R O O T S

34 Beispiel: Common Ancestor Pane (3) Antwort: Keiner Hier wurde tatsächlich an der gleichen Stelle parallel geändert! Absprache mit dem Kollegen / Co-Author erforderlich! Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 2-34 R O O T S

35 Synchronisieren: Aktionen zur Konfliktauflösung Override and Update (Menupunkt) Überschreibt lokale Version mit Repository-Inhalt Override and Commit (Menupunkt) Überschreibt Repository-Version mit lokaler Version Nie ohne vorherige Kommunikation mit dem Autor der Repository-Version! Merging (Manueller Vorgang) Selektive Übernahme einzelner Änderungen der Datei im Compare Editor Nur Übernahme von Repository-Stand in lokale Version, nicht umgekehrt! Anschließend Mark as Merged auf lokaler Version (Menupunkt) Lokale Version wird nun als aktueller als die aus dem Repository angesehen Beim nächsten Commit wird die Version im Repository überschrieben! Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 2-35 R O O T S

36 Tagging (= Baselining) minicalc.dsw h minicalc.h c minicalc.cpp rc minicalc.rc Release 1 Release 1 Release 1 Release Release Release Release 2 4 Release 2 Jede Version im Repository kann ein globales Label (z.b. "Release 1") erhalten Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 2-36 R O O T S

37 Kapitel 2: Software Configuration Management Vergleich von Subversion (SVN) und CVS Versionierung von Verzeichnissen Globale Commit-Nummerierung Atomare Commit-Aktionen

38 Subversion kann mehr als CVS: 1. Versionierung von Verzeichnissen Dateien und Verzeichnisse zu löschen, umzubenennen und zu verschieben entspricht einer neuen Version des umgebenden Verzeichnisses Hier eine Versionsänderung von /usr/src/proj /usr/src/proj /usr/src/proj gui_src gui_doc gui schedule src doc schedule arc.c zbuf.c plan.doc arc.c zbuf.c plan.doc Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 2-38 R O O T S

39 Subversion kann mehr als CVS: 1. Versionierung von Verzeichnissen Es ist in Subversion möglich Dateien und Verzeichnisse zu löschen, umzubenennen und zu verschieben Warnung Man muss diese Operationen mit einem Subversion Client durchführen! Siehe Folie Wichtige Links Führt man es selbst auf Systemebene durch wird Subversion nichts vom Umbenennen oder Verschieben erfahren. Es wird annehmen eine Datei wurde gelöscht und eine andere hinzugefügt! Man sollte tunlichst vermeiden, versehentlich die.svn Ordner innerhalb der Arbeitskopie zu verändern! Sie enthalten die Meta-Informationen für SVN über die zwischen den Abgleichen mit dem Repository geschehenen Änderungen auf Dateiebene Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 2-39 R O O T S

40 Subversion kann mehr als CVS: 2. Globale Versions-Nummerierung CVS weist jeder Datei ihre eigenen Versions-Nummern zu A B C D Problem: Es ist nicht einfach zusehen welche Versionen verschiedener Dateien zusammengehören Gehört Version 1.0 von Datei A wirklich zu Version 1.1 von Datei B? Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 2-40 R O O T S

41 Subversion kann mehr als CVS: 2. Globale Versions-Nummerierung SVN weist jeder Datei die bei einem Commit verändert wurde die selbe Versions-Nummer zu. A B C D Build Build? 5 6 Vorteil: Dateiversionen die zusammengehören sind auf einen Blick zu erkennen: Zu einer Projektversion V gehören alle Elemente mit Versionsnummer V oder kleiner als V Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 2-41 R O O T S

42 Subversion kann mehr als CVS: 2. Globale Versions-Nummerierung Ein Roll back auf eine alte Version ist einfach, selbst ohne Tags Gehe zurück zu Version 3 A B C D Build Tagging sollte für wichtige Zwischenstände trotzdem genutzt werden Release 1.0 alpha ist leichter zu merken als Version Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 2-42 R O O T S

43 Subversion kann mehr als CVS: 3. Atomic commits Netzwerkfehler oder andere Probleme können zu unvollständigen Commits führen (nicht alle Dateien wurden commitet ) Wenn dies passiert, hinterlässt CVS das Repository in einem inkonsistenten Zustand. SVN führt bei unvollständigen Commits einen Roll back durch. SVN benutzt ein Datenbanksystem um das Repository zu speichern und kann daher Commits als atomare Transaktionen implementieren! Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 2-43 R O O T S

44 Kapitel 2: Software Configuration Management Struktur von Subversion-Repositories Spezielle Ordner Optionen

45 Repository Layout: Spezielle Ordner trunk Enthält die aktuelle Entwicklungslinie (wie HEAD in CVS) Also den trunk auschecken! tags Enthält unveränderliche Versionen des Projekts Für Releases, Milestones, Backups branches Enthält alternative Entwicklungszweige des Projekts Für Untergruppen eines Teams oder parallele Entwicklung verschiedener Varianten Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 2-45 R O O T S

46 Repository Layout: Alles nur Konvention! Vorherige Folie ist nur Konvention! trunk, branches, tags sind für Subversion normale Ordner Es ist bloß der Subversive-Client, der sie besonders behandelt Ob das geschehen soll, kann als Option angegeben werden Man darf die Ordner des Projekts organisieren wie man möchte! Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 2-46 R O O T S

47 Kapitel 2: Software Configuration Management Installation des Subversive Plugins für Eclipse Hinweise zur Installation des Subversive Plugins in Eclipse finden Sie in einem Exkurs -Foliensatz zum aktuellen Kapitel und auf der Vorlesungswebsite.

48 Wichtige Links Subversion Buch Subversion Server subversion.tigris.org Subversion Clients als Erweiterung für den Windows Explorer TortoiseSVN (nur für Windows) Subversion Clients als Plugins für Eclipse Subversive Wir empfehlen Subversive zu benutzen Homepage: Plugin Download Seite: Subclipse Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 2-48 R O O T S

49 Kapitel 2: Software Configuration Management Clear Case

50 ClearCase VOB (Versioned Object Base) Sicheres Repository aufbauend auf objektorientierter Datenbank Zugriff nur mit ClearCase möglich Speichert alle versionierten Daten bugfix 0 1 Release 1 Source code 0 2 develop Directories Binaries Wer hat was, wann, warum getan? Virtuelles Dateisystem Regelbasierte Konfiguration 4 2 Release 2 Beliebig viele VOBs im Netzwerk Verteile Datenbank Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 2-50 R O O T S

51 Virtual File System bei ClearCase src VOB foo.h foo.c emacs make gcc grep eclipse WIN / UNIX / MAC M V F S src foo.c foo.h Softwareentwicklungswerkzeuge Versioned Object Base (VOB)

52 Regelbasierte Arbeitskopie-Verwaltung Prinzip: regeldefinierte Auswahl von Objekten / Versionen Sichtdefinition durch benutzerspezifische Regelmenge Regeln agieren als Filter: Auswahl einer bestimmten Objektversion verhindert Zugriff auf alle anderen Versionen des selben Objekts Projektion der ausgewählten Versionen als normaler Verzeichnisbaum Statische Regelauswertung Auswertung der Regeln zum Zeitpunkt des Arbeitsbeginns ausgewählte Versionen werden in den privaten Arbeitsbereich kopiert der Benutzer muss am Ende explizit die Synchronisation anstoßen Dynamische Regelauswertung (ClearCase) Auswertung der Regeln zum Zeitpunkt des Objektzugriffs Lesevorgänge direkt aus der VOB längstmöglich aktuellster Stand Objekte werden erst beim ersten Schreiben in den Arbeitsbereich kopiert Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 2-52 R O O T S

53 Regelbasierte Arbeitskopie-Verwaltung: Regelsyntax und -semantik ks/clrc_ug/sgi_html/ch05.html Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 2-53 R O O T S

54 ClearCase Views View Transparentes Arbeiten mit verschiedenen Releases des gleichen Projekts Zeig mir Version 2.20 Arbeiten in Echtzeit Sofortiger Zugriff auf den gesamten Datenbestand Downloads finden nur bei Zugriff statt Kein komplettes Kopieren! Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 2-54 R O O T S

55 ClearCase Views: Private Storage View Lokale Kopien ermöglichen das Arbeiten ohne Netzzugriff Synchronisation mit der Datenbank erfolgt automatisch Merging erfolgt automatisch Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 2-55 R O O T S

56 ClearCase Views Alle Objekte im VOB sind schreibgeschützt Check-Out Ein Entwickler muß ein check-out-kommando absetzen, um ein Objekt verändern zu können Dieses wird dann in den privaten Speicherbereich kopiert, ist aber noch unter dem ursprünglichen Namen und Pfad ansprechbar Check-In Das check-in-kommando erzeugt eine neue Objektversion im VOB und löscht die private Kopie Locking: Nur derjenige Entwickler, der das check-out-kommando abgesetzt hat, darf die neue Objektversion auch wieder einchecken Variante: unreserved check-out : first check-in wins ; alle anderen müssen mergen Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 2-57 R O O T S

57 Verteile Entwicklung Paralleles Entwickeln mit geographisch verteilten Projekt- Teams Automatische Updates und Kopien der VOBs Jeder branch hat einen Master -Server s. nächste Folie Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 2-58 R O O T S

58 Verteile Entwicklung: Master pro Branch foo.c foo.c \america 1 \europe \america 1 \europe Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 2-59 R O O T S

59 Kapitel 2: Software Configuration Management ClearCase Build Management Verwaltung der Abhängigkeiten von Artefakten Reproduzierbare Neugenerierung abgeleiteter Artefakte

60 Build Management mit herkömmlichen Werkzeugen (make, ant) Keine automatisierte Abhängigkeitsanalyse Abhängigkeiten werden vom Benutzer manuell beschrieben Das ist aber in einer sich schnell ändernden Umgebung sehr aufwendig und fehleranfällig Kein Binary sharing Das "normale" Make (oder Ant) weiß nichts darüber, dass ein Kollege evtl. ein aufwendig zu erstellendes abgeleitetes Objekt schon erzeugt hat Kein Bill of materials unklar ob zwei abgeleitete Produkte gleichen Namens (foo.o) wirklich gleich sind, da nicht klar ist, ob sie auch aus den gleichen Zutaten und nach der gleichen Rezeptur erstellt wurden Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 2-61 R O O T S

61 Build Management mit ClearCase Verwaltung von Informationen zum reproduzierbaren Erstellen von abgeleiteten Objekten Technische Grundlage Durch das VFS ist es möglich, die I/O-Zugriffe vom Compiler oder anderen Werkzeugen auf alle beteiligten Objekte erfassen und protokollieren zu lassen. clearmake erledigt diese Aufgabe Protokollierung der benötigte Daten (Auditing) Zutatenliste (bill-ofmaterials) Korrekte Versionen aller Quell-Dateien und anderer beteiligter Objekte Namen und Versionen der verwendeten Werkzeuge benutzte Parametereinstellungen Resultierende nützliche Eigenschaften binary sharing: Abgeleitete Objekte können von verschiedenen Benutzern genutzt werden minimal rebuilding: Nur die notwendigsten Operationen zum Erstellen eines abgeleiteten Objekts müssen durchgeführt werden

62 Build Management mit ClearCase clearmake audit on invoke build script audit off additional information /bin/cc -g parse.c view Config Record File System I/O Audit HP/UX /bin/cc -g parse.c Bill-of-material = Stückliste der Zutaten für die Herstellung dieses abgeleiteten Objektes. VOB repository

63 Zusammenfassung: SCM de Luxe Virtuelles Dateisystem Transparenz der Datenhaltung Regelbasierte Konfiguration des Arbeitsbereiches Flexibilität Dynamische Regelauswertung Aktualität Automatisches Merging Geringer Integrationsaufwand Build Management Reproduzierbare build -Ergebnisse, Effizienz durch minimal rebuilding ECA-Regeln Workflow-Management Verteilung, automatische Spiegelung, verteiltes Building Unterstützung für internationale Unternehmen Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 2-64 R O O T S

64 Kapitel 2: Software Configuration Management Von zentraler zu verteilter Versionskontrolle Nachteile zentralisierter Ansätze Prinzip der verteilten Versionskontrolle Vergleich zentrale dezentrale Versionskontrolle Werkzeuge

65 Austausch halbfertiger Zwischenstände via zentralem SCM-System Peter und Lisa haben unabhängig am gleichen Projekt gearbeitet Peter will Lisa seine noch nicht ganz ausgegorenen Änderungen geben, damit sie sie integriert Ohne SCM: Via , etc. Problem: Keine Unterstützung für Abgleich (Synchronize & Merge) Mit SCM: Via commit und update Problem: Der inkonsistente Zustand erscheint im Repository betrifft Andere? checkout / update Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 2-66 R O O T S

66 Austausch halbfertiger Zwischenstände via zentralem SCM-System Peter und Lisa haben unabhängig am gleichen Projekt gearbeitet Peter will Lisa seine noch nicht ganz ausgegorenen Änderungen geben, damit sie sie integriert Ohne SCM: Via , etc. Problem: Keine Unterstützung für Abgleich (Synchronize & Merge) Mit SCM: Via commit und update Problem: Der inkonsistente Zustand erscheint im Repository betrifft Andere? checkout / update Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 2-67 R O O T S

67 Probleme Commit von inkonsistenten Zuständen inkonsistenter Zustand betrifft Andere Regel: Kein commit von inkonsistenten Zustände! Niemals! Commit inkonsistenter Zustände verhindern Spezielle commiter Rolle Nur sehr erfahrene Entwickler haben das Recht zum Commit Sie erhalten jeden Änderungsvorschlag als patch den sie erst auf Ihrer eigenen Arbeitskopie testen und gegebenenfalls ablehnen Folgeproblem: Engpass Kein commit inkonsistenter Zustände Synchronize & Merge nicht für Abgleich von Zwischenzuständen nutzbar Fehleranfälliger manueller Abgleich von Zwischenzuständen (Peter Lisa) Commit & Revert nicht für Zwischenzustände nutzbar Es sammlen sich umfangreiche Änderungen an Rücksetzen auf Repository-Stand entsprechend verlustreich und aufwendig Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 2-68 R O O T S

68 Verteilte Versionskontrolle Multiple, verteilte Repositories Jede(r) hat ein oder mehrere lokale Repositories Mehrere Verschieden Projekte oder verschiedene Aufgaben im Projekt Repository kann geklont werden inkl. der gesamten Versionshistorie! Ab jetzt kann man lokal weiterarbeiten Mit allen Funktionalitäten (commit, branch, switch brach, merge, ) Man kann diese Funktionen lokal auch für Unfertiges verwenden! Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 2-69 R O O T S

69 Verteilte Versionskontrolle Multiple, verteilte Repositories Checkout, Commit, Branch, Switch Branch, geschehen lokal Sehr schnell Unabhängig von Netzverbindung und Server Fokus auf Gesamt-Repository statt einzelnen Artefakten Commit = Menge von Änderungen ( Change set / Patch ) Jedes Commit hat eine eindeutige ID Repository-Zustand = ID einer Änderung (Zustand nach dieser Änderung) commit #e34b Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 2-70 R O O T S

70 Verteilte Versionskontrolle Multiple, verteilte Repositories Repositories können miteinander abgeglichen werden Pull: Holen von Änderungen aus anderem Repository Push: Übertragen von Änderungen in ein anderes Repository Pull beinhaltet bei Bedarf automatisches Merge Merge wird als eigene Änderung verwaltet (Hat eigene ID) In der Abb. nehmen wir an es sei kein Merge nötig gewesen update commit push / pull Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 2-71 R O O T S

71 Verteilte Versionskontrolle Multiple, verteilte Repositories Technische Gleichberechtigung Jedes Repository kann geklont werden und von jedem kann abgeglichen werden Egal welches die ursprüngliche Kopie war Organisatorische Zentralisierung (wenn gewünscht) Vereinbarung, welches Repository als Master benutzt wird Evtl. durch Zugriffsrechte für push / pull / clone unterstützt pull Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 2-72 R O O T S

72 Branch vs. Branch + Switch Branch Branch + Switch newbranch newbranch oldbranch oldbranch oldbranch oldbranch Neuer Branch erstellt Weiterarbeiten im alten Branch Neuer Branch erstellt Weiterarbeiten im neuen Branch Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 2-73 R O O T S

73 Merge vs. Cherry Pick Merge Cherry Pick otherbranch otherbranch Commit des Merges Commit des Cherry Pick selektiert selektiert currentbranch currentbranch Alle Änderungen bis zum selektierten Commit in den aktuellen Branch übernehmen Branches synchronisieren Nur die Änderungen übernehmen, die im selektierten Commit durchgeführt wurden z.b. Bugfix selektiv übernehmen Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 2-74 R O O T S

74 Verteilter Versionskontrolle Multiple, lokale Repositories Man kann auch lokale Repositories weiter Clonen / Kopieren Mitten in unfertigem Task für den es keinen eigenen Branch gibt zu einer anderen Aufgabe wechseln, die ein pull erfordert Repository-Kopie anlegen, in der der aktuelle Stand erhalten bleibt Im Original pullen und auf offiziellem Stand weiter arbeiten Zwischendurch auch in der Kopie weiterarbeiten und comitten Wenn die Arbeit in der Kopie fertig ist, im Original die Änderungen pullen und Kopie löschen commit pull commit Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 2-75 R O O T S

75 Der GIT Ordner GIT-Ordner = Working Tree (SmartGIT) = GIT-Repository + Arbeitskopie GIT-Ordner = Working Tree (in SmartGIT) GIT-Repository Arbeitskopie Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 2-76 R O O T S

76 Spezielle Ordner auf der Festplatte GIT Nur ein Ordner mit Metadaten und Daten auf der obersten Ebene des git-ordners SVN Ein Metadaten-Ordner in jedem Unterordner eines svn-ordners Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 2-77 R O O T S

77 Keine eigene Zugriffskontrolle GIT hat keine eigene Zugriffskontrolle Es wird statt dessen der Mechanismus genutzt, der gerade verfügbar ist Zugriff auf: über: Zugriffskontrolle Lokale Datei Betriebssystem Zugriffskontrolle des BS Remote Datei FTP Username + Passwort HTTPS Username + Passwort SSH Private Key (lokal) + Public Key (remote) Remote Repository GIT Read only Remote Datei Datei auf anderem Host Zugriff direkt auf Datei Remote Repository GIT-Gegenstelle auf anderem Host Zugriff über Server-Prozess Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 2-78 R O O T S

78 Aktuelle GIT-Clients Egit Plugin für Eclipse Platformunabhängig, Open Source Kommendes Release soll auch den Synchronize-View und vieles andere unterstützen, was zur Zeit noch etwas halbherzig funktioniert. SmartGIT Kommerzielles Produkt aber für nichtkommerzielle Anwendung frei Auf allen Platformen verfügbar Stabil, ausgereift Leider nicht in Eclipse integriert Empfehlung Vorerst SmartGIT nutzen aber Fortschritt von Egit verfolgen Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 2-79 R O O T S

79 Kapitel 2: Software Configuration Management Arbeiten mit Branches (am Beispiel SmartGIT) Log-Ansicht In anderen Branch wechseln und dort arbeiten Zurückwechseln und Änderungen aus anderem Branch übernehmen

80 Die Log Ansicht Bereiche Branches und ihre Commits (neuere Comits weiter oben) Kommentar (zu selektiertem Commit) Inhalt der selektierten Datei Geänderte Dateien (im selektiertem Commit) Alt Neu Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 2-81 R O O T S

81 Die Log Ansicht Der Commit-Bereich GIT-Terminologie origin = Ursprungsrepository (aus dem das aktuelle / lokale Repository geklont wurde) tracking branch = Entsprechung eines lokalen Zweiges in origin Bsp: origin/master ist tracking branch von master Visualisierung Grünes Etikett : Stand eines lokalen Zweiges Gelbes Etikett : Stand eines Zweiges in origin Grünes Dreieck : Aktueller Zweig im lokalen Repository Lokaler master und sein tracking brach sind auf gleichem Stand Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 2-82 R O O T S

82 Switch Wechseln in anderen Branch Aktueller Branch Beim Wechsel in Brach B automatisch ein pull der Änderungen aus dem tracking branch von B durchführen Beim Wechsel nach Branch B Änderungen die im aktuellen Branch NICHT commited sind nach B übernehmen Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 2-83 R O O T S

83 Log nach erstem Commit und Push in malwiedereintest Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 2-84 R O O T S

84 Fährtenlesen im Log 1. Sebastian hat den mitsmartgit branch angelegt in dem sich seit dann nichts mehr getan hat 2. Ein Unbekannter hat den malwiedereintest branch angelegt in dem Gero um 13:53 was weiter committed hat 3. Um 13:56 hat Gero dann im master einen konflikttächtigen commit gemacht 4. Keine der lokalen Änderungen wurden bisher gepushed. 5. Der Autor dieses Screenshots arbeitete gerade im master Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 2-85 R O O T S

85 Pullen und Merge-Versuch mit Konflikt Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 2-86 R O O T S

86 Konfliktanzeige und auflösung Doppelklick auf Datei mit Konflikt Compare Editor öffnen: Nach Abgleich der Änderungen Save und Stage! Stage Mark as merged bei SVN Die gespeicherten Änderungen lösen den Konflikt Sie sind comitted-bereit (werden aber noch nicht comitted!) Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 2-87 R O O T S

87 Zustand nach Konfliktauflösung und Stage Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 2-88 R O O T S

88 Commit der Konfliktauflösung Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 2-89 R O O T S

89 Log nach Konfliktauflösungs-Commit Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 2-90 R O O T S

90 Auf konfliktbereinigtem Stand weiter arbeiten (nächstes commit) Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 2-92 R O O T S

91 Fertig Zurückwechseln in den master Von hier (aktueller Branch) Nach da (selektierter Branch) Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 2-93 R O O T S

92 Änderungen aus malwiedereintest in master übernehmen Merge Merge von dort (selektierter Branch + Commit) Merge nach hier (aktueller Branch) Echter Merge (kein chery pick ) Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 2-94 R O O T S

93 Merge durchgeführt Beide branches auf gleichem Stand! Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 2-95 R O O T S

94 Der krönende Abschluss Pushen! und nun auch synchron mit origin/master! Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 2-96 R O O T S

95 Kapitel 2: Software Configuration Management Zusammenfassung und Ausblick Vergleich der Ansätze Weiterführende Informationen

96 SCM-Ansätze und Werkzeuge Vergleich Zentral (z.b. SVN) Operationen Verteilt Lokal, linear Checkin Checkout Update (incl. 3-Wege-Merge) Commit Lokal, branch management Branch Switch Merge Verteilt (z.b. GIT) Operationen Verteilt Clone Pull (incl. 3-Wege-Merge) Push Lokal, linear Create repository Checkout (implizit bei pull ) Commit Lokal, branch management Branch Switch Merge Cherry pick selektives Merge eines Commits aus anderem Branch Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 2-98 R O O T S

97 SCM-Ansätze und Werkzeuge Vergleich Zentral (z.b. SVN) Konzepte Es gibt nur ein Repository Interaktion nur über zentralen Server Dateiweise Historie Tracking von Umbenennungen Verwaltungsdaten (.svn- Unterordner) in jedem Ordner des Arbeitsbereich Ein.svn-Ordner enthält nur lokale Metadaten Er enthält hauptsächlich Informationen über was sich seit dem letzten Abgleich mit dem Repository geändert hat Verteilt (z.b. GIT) Konzepte Gleichberechtigte Repositories Zentrale Instanz organisatorisch möglich Repository-weite Historie Änderung hat eindeutige Id Verwaltungsdaten (.git- Unterordner) nur im obersten Ordner des Arbeitsbereichs Der.git-Ordner ist das komplette lokale Repository Er enthält unter anderem komprimierte Fassungen aller Dateiversionen seit Anlegen des Repositories Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 2-99 R O O T S

98 Vorteile Verteilter Versionskontrolle Eigene, lokale Versionskontrolle Nicht erst dann einchecken, wenn wirklich alles läuft Eigene inkrementelle Historie, Rollbacks auch lokal möglich Lokal Arbeiten ist sehr schnell Diff, Commit und Revert sind rein lokal kein Netzwerkverkehr nötig Branching und Merging ist leicht Branch = Clone Branch im repository oder clone des repository. Merge = Pull Beim pull wird automatisch ein merge durchgeführt Partielle Integration ist leicht Entwickler können ihre Änderungen untereinander abgleichen Änderung eines zentralen Masters erst nach partieller Integration Wenig Management erforderlich Schneller Start (einfach clone oder create repository ) Nur der eigene Rechner muss andauernd laufen Kein Usermanagement erforderlich Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite R O O T S

99 Nachteile Verteilter Versionskontrolle Es gibt keine wirkliche neueste Version Kann man durch ein dediziertes Repository emulieren Es gibt keine globalen Versionsnummern Jedes Repository verwaltet seine eigene Änderungshistorie Aber man kann Releases mit sinnvollen Namen taggen Ein zentrales Backup ist dennoch sinnvoll auch wenn gerne dagegen argumentiert wird eventuell hat nicht jeder alle Änderungen mitbekommen, also kann man sich nicht auf andere Repositories als Backup verlassen Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite R O O T S

100 Listen weiterer SCM Werkzeuge Wikipedia Sehr umfangreiche Liste, mit oft guten Fortsetzungen zu den einzelnen Werkzeugen Wikipedia Versuch eines tabellarischen Vergleichs der Systeme Teilweise gut, aber hoffnungslose Sisyphos-Arbeit... Andere ls/ Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite R O O T S

101 Vergleiche von SCM Werkzeuge Wikipedia (allgemein) Versuch eines tabellarischen Vergleichs der Systeme Teilweise gut, aber hoffnungslose Sisyphos-Arbeit... Wikipedia (nur open source) nagement_software Andere neutrale Vergleiche (Stand 29. Feb. 2008) Nicht ganz unparteiische Vergleiche Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite R O O T S