3. Versions- und Konfigurationsmanagement. Typischer Weg der Software-Entwicklung

Transkript

1 3. Versions- und Konfigurationsmanagement Typischer Weg der Software-Entwicklung Inkrementelle Entwicklungsschritte Varianten der Versionskontrolle Repository Typischer Arbeitszyklus Auflösung von Konflikten Aufgabenteil auswählen Programmstück kodieren Programmstück testen kleiner Fehler Fehler unklar kleine Überarbeitung Korrekturversuch Einbau/Nutzung von Debuginformationen kleine Lösungsvariante Literatur: [CFP07] B. Collins-Sussman, B. W. Fitzpatrick, C. M. Pilato, Version Control with Subversion, [als PDF von Subversion-Webseite frei verfügbar] läuft nicht fertig fertig Umstrukturierung große Lösungsvariante Software-Versionen Software entwickelt sich inkrementell, bei Versuchen muss der Weg zurück möglich sein Versionsbaum Paket 1 V 1 V 2 V 3 V 4 V 5 Paket 2 V 1 V 2 V 3 V 4 V 5 V 6 Paket 3 V 1 V 2 V 3 V 4 V 5 Inkrement 1 V 6 V 7 Inkrement 2 Verwaltung von Software Die gemeinsame Entwicklung von Software hat u. a. folgende Aufgaben zu lösen: wie kann ein Entwickler seine eigene Softwareentwicklung koordinieren wie bekommen andere Entwickler mit, was der aktuelle Entwicklungsstand ist wie wird aus den einzelnen Dateien effizient das lauffähige System kompiliert Die ersten beiden Fragen beantwortet ein Versionskontrollsystem die letzte Frage fordert die Erweiterung zum Softwarekonfigurationsmanagementsystem (-> Ant) 49 50

2 Versionskontrolle: konservative Variante Dateien werden zentral im Repository verwaltet Entwickler checkt zu ändernde Software aus Entwickler erhält damit lokale Kopie zur Bearbeitung Während der Entwickler an der Software arbeitet, kann niemand anderes diese Software bearbeiten (erhält die Situation klärenden Hinweis) Entwickler checkt lokale Kopie (mit Änderungsverweis) wieder ein; jeder kann diese Kopie zur erneuten Bearbeitung auschecken Vorteil: garantiert nur ein Bearbeiter Nachteile: keine gleichzeitige Arbeit an unterschiedlichen Programmstellen, wartende Entwickler, vergessenes Einchecken Realisierung von Repository sehr unterschiedlich lösbar (Datenbanksystem, Aufsatz auf Filesystem) Hinweis: Generell sollte das Einchecken mit einer Prüfung verbunden sein 51 Versionskontrolle: progressive/chaotische Variante Dateien werden zentral im Repository verwaltet Entwickler checkt zu ändernde Software aus Entwickler erhält damit lokale Kopie zur Bearbeitung andere Entwickler können gleichen Programmcode auschecken erst beim Einchecken wird geprüft, ob seit dem Auschecken zwischenzeitliche neue Version eingecheckt wurde, wenn ja, passiert Versionsabgleich, Konflikt muss gelöst werden Vorteil: massive parallele Arbeit wird möglich, kein Ausbremsen anderer Entwickler Nachteil: Chaos bei häufig veränderten Ressourcen Lösung: für selten genutzte Dateien progressiver, für sehr kritische oder häufig genutzte Dateien konservativer Ansatz bisher Open Source: progressiv, kommerziell: konservativ 52 Übungsaufgabe Ein klassisches Problem der Versionierung ist der Fall, dass ein Entwickler X alleine bearbeitet, ein anderer Entwickler Y alleine bearbeitet und beide (ohne Probleme) ihre Änderungen einchecken. Das alte Programm lief ohne Probleme, die neue Variante läuft nicht, da gegenseitige Abhängigkeiten nicht berücksichtigt worden. Schreiben Sie ein einfaches lauffähige Programm mit den Klassen A und B. Überlegen Sie sich Änderungen von A nach A und von B nach B, so dass A mit B und A mit B ohne Probleme laufen, A mit B zusammen aber nicht läuft. 53 Architektur von Subversion [CFP07] 54

3 Repository anlegen Hinweis: Sie werden bei der Arbeit mit Subversion typischerweise nur sehr wenige Befehle benötigen, hier werden weitere Befehle vorgestellt, die das Üben auf dem eigenen Rechner ermöglichen. Dabei immer das lesenswerte freie Buch [CFP07] beachten Hinweis: Anlegen passiert durch zentralen Administrator (FH- Regelung im Praktikum) G:\> svnadmin create /svnrepos hier wird u. a. eine Datenbank angelegt, diesen Ordner nie von Hand bearbeiten svnadmin ist Administrationswerkzeug und wird von einfachen Nutzern nie genutzt Repository in Ordnerstruktur organisiert, diese Ordner werden vom Nutzer selbst angelegt Man beachte, dass immer / genutzt werden muss 55 Einspielen der Daten Es werden lokale Daten in das Repository eingespielt Zentrale Versionsmanagementaufgabe: Sinnvolle Dateistruktur für das Projekt anzulegen Typischerweise werden generierbare Dateien (*.class) nicht unter Versionskontrolle genommen, evtl. sinnvoll, fertige Releases vollständig einzuchecken (mit Executable), dieses aber nicht veränderbar Daten vor dem Einspielen in eine sinnvolle Repository-Struktur bringen G:\>svn import g:/antspiel/src file:///g:/svnrepos/mvc/source -m:"ausgangsdaten" file steht für lokales Verzeichnis, hier normalerweise URL file://localhost/svnrepos file:///g:/svnrepos oder "file:///g /svnrepos" Hinweis: import Befehl wird nur einmal für Daten genutzt, danach zum Ändern immer die folgenden Befehle nutzen 56 Auschecken der Daten Ansatz: Daten werden immer aus Repository in lokalen Ordner kopiert G:\arbeit>svn checkout file:///g:/svnrepos/mvc/source quelle A quelle/de A quelle/de/kleuker A quelle/de/kleuker/xview.java A quelle/de/kleuker/xmodel.java A quelle/de/kleuker/xcontroller.java A quelle/de/kleuker/xstarter.java A quelle/de/kleuker/xmodellistener.java Ausgecheckt, Revision 1. G:\arbeit>dir quelle :28 <DIR> :28 <DIR> :28 <DIR>.svn :28 <DIR> de.svn ist zentrales Verwaltungsverzeichnis zum Erkennen von Änderungen (verwaltet u. a. den Stand beim Auschecken) Danach ist lokale Bearbeitung der Dateien möglich 57 Einchecken der Daten ausgecheckte Dateien beliebig veränderbar löschen, kopieren und verschieben, an Subversion melden Mit commit können ganze Verzeichnisse eingecheckt werden, man kann aber auch Dateien angeben (nur Neues wird kopiert), z. B. (ohne m mit Kommentar oder f File nicht ausführbar) G:\arbeit\quelle\de\kleuker>svn commit XView.java -m"groesse angepasst" Sende XView.java übertrage Daten. Revision 2 übertragen. G:\arbeit\quelle\de\kleuker>svn commit -m"groesse 450" Sende kleuker/xview.java übertrage Daten. Revision 3 übertragen. Bei Problemen wird das Einchecken nicht durchgeführt Einchecken ist atomar (ganz oder gar nicht) 58

4 Datenunterschiede erkennen diff-befehl zeigt zeilenweise Unterschiede (bei eigener Arbeit, aber auch zwischen zwei Dateien), hier XStarter.java bearbeitet G:\arbeit\quelle\de\kleuker>svn diff XStarter.java Index: XStarter.java ================================================== --- XStarter.java (Revision 8) +++ XStarter.java (Arbeitskopie) -3,9 +3,9 public class XStarter { public static void main(string[] args) { - XModel x= new XModel(); - new XView(x); - new XController(x); + XModel xmodel= new XModel(); + new XView(xmodel); + new XController(xmodel); 59 Konfliktbearbeitung (1/5) Annahme: wir bearbeiten XStarter.java, diese Datei wurde nach uns von anderem Entwickler zwischenzeitlich eingecheckt G:\arbeit\quelle\de\kleuker>svn commit XStarter.java -m"variablennamen angepasst" Sende XStarter.java svn: übertragen fehlgeschlagen (Details folgen): svn: Out of date: '/MVC/source/de/kleuker/XStarter.java' in transaction '6' Lösungsansatz: Zunächst eigene Dateien aktualisieren G:\arbeit\quelle\de\kleuker>svn update G XStarter.java Aktualisiert zu Revision 5. U: selbst nicht bearbeitet, aber neue Version im Repository G: lokal und im Repository bearbeitet, von Subversion gelöst (merge) [???!!!] C: selbst bearbeitet und im Repository bearbeitet, Subversion hat keinen Lösungsvorschlag 60 Konfliktbearbeitung (2/5) merge muss kontrolliert werden (Änderungen an unterschiedlichen Stellen) hier Ergebnis (überlegen Sie, was anderer Implementierer gemacht hat): public class XStarter { public static void main(string[] args) { XModel xmodel= new XModel(); new XView(xmodel); new XController(xmodel); new XView(x); // zweiter View new XController(x); // zweiter Controller Konfliktbearbeitung (3/5) Bei erkanntem Konflikt auf Datei XStarter.java werden bei update folgende Dateien angelegt G:\arbeit\quelle\de\kleuker>svn update C XStarter.java Aktualisiert zu Revision 11. G:\arbeit\quelle\de\kleuker>dir XStarter.* : XStarter.java : XStarter.java.mine : XStarter.java.r : XStarter.java.r11.java.mine: unsere aktuelle Variante (falls.java verändert).r<alt>: Version beim Auschecken.r<neu>: aktuelle Version aus dem Repository.java: unsere Datei mit Konfliktmarkierungen (wenn Subversion Überarbeitung für möglich hält) Nutzer muss dann von Hand die wünschenswerte Lösung komponieren (diff ist hilfreich) 61 62

5 Konfliktbearbeitung (4/5) Beispiel für Konfliktbeschreibung in Datei package de.kleuker; public class XStarter { public static void main(string[] args) { XModel xmodel= new XModel(); <<<<<<<.mine new XView(xmodel); new XController(xmodel); new XView(xmodel); new XController(xmodel); ======= XView[] views= {new XView(xmodel), new XView(xmodel); new XController(xmodel); for(int i=0;i<2;i++) views[i].setlocation(0+i*500,0); >>>>>>>.r11 63 Konfliktbearbeitung (5/5) Nutzer überarbeitet Konflikt eine Variante: eigene Änderungen zurückziehen (lokale Dateien automatisch gelöscht) svn revert XStarter.java Konfliktlösung muss Subversion mitgeteilt werden (lokale Dateien automatisch gelöscht) svn resolved XStarter.java ohne Meldung der Lösung kann keine commit erfolgreich sein (theoretisch neues Problem möglich, falls zwischenzeitlich erneut neue Version eingespielt) Generell gilt, dass häufig auftretende Konflikte auf eine mangelnde Projektorganisation oder Kommunikation hindeuten 64 History-Informationen svn log r4 Administrator :59: (Sun, 11 Feb 2007) 1 line ArrayStrukur r3 Administrator :12: (Sat, 10 Feb 2007) 1 line Variablennamen angepasst r2 Administrator :50: (Sat, 10 Feb 2007) 1 line zwei Models und Views r1 Administrator :40: (Sat, 10 Feb 2007) 1 line Ausgangsdaten Möglichkeit, bestimmte Releases anzusehen: svn log r 4:3 Möglichkeit History einer Datei anzusehen (nur Releases mit Änderung angezeigt) : svn log XModel.java 65 Arbeit mit alten Versionen man kann aktuellen Stand mit Revisionen vergleichen svn diff r3 XStarter.java man kann zwei Revisionen vergleichen svn diff r2:3 XStarter.java man kann sich alten Stand ansehen (evtl. umlenken) svn cat r2 XStarter.java svn cat r2 XStarter.java > analysedatei Inhalt des Repository ansehen (-v verbose häufiger nutzbar) G:\arbeit\quelle\de\kleuker>svn list -v file:///g:/svnrepos/mvc/source/de/kleuker 1 Administ 1566 Feb 10 17:16 XController.java 1 Administ 1186 Feb 10 17:16 XModel.java 1 Administ 90 Feb 10 17:16 XModelListener.java 11 Administ 313 Feb 11 09:59 XStarter.java 4 Administ 1223 Feb 10 17:40 XView.java Auschecken einer alten Revisionsnummer (richtigen Ort beachten, danach normal mit commit und update bearbeitbar) svn checkout file:///g:/svnrepos/mvc/source/de -r3 66

6 Versionsnummern Versionsnummern einzelner Dateien werden bei commit hochgezählt Subversion nutzt Versionsnummern für vollständige Bäume, bedeutet, dass Revisionsnummer für alle Dateien (auch nicht geänderte) hochgezählt wird (anders in anderen Versionsmanagementwerkzeugen) mit Abfrage der History feststellbar, ob Datei überhaupt in der Version geändert wurde Statusabfrage zeigt aktuelle Versionsnummer und in welcher Version letzte Änderung (formal alle in Version 19) G:\arbeit\quelle\de\kleuker>svn status -v Administrator Administrator XView.java Administrator doku Administrator doku/comment.txt 11 1 Administrator XModel.java 11 1 Administrator XController.java Administrator XStarter.java 11 1 Administrator XModelListener.java 67 Status abfragen Vor commit oder update immer sinnvoll, den aktuellen Arbeitsstatus abzufragen, gibt Informationen welche Änderungen durchgeführt wurden A C D M R?! ~ I X Soll hinzugefügt werden (add) Steht in einem Konflikt, muss vor commit gelöst werden Soll gelöscht werden (delete) Inhalt wurde verändert (modify) Soll ersetzt werden (gleicher Name, neuer Inhalt, replace) Befindet sich nicht unter Versionskontrolle (kein Problem) Unter Versionskontrolle, fehlt aber (irrtümlich gelöscht) Typ in Repository und Arbeitsbereich passt nicht Nicht unter Versionskontrolle, Ignorieren vereinbart Nicht versioniert, aber als extern gekennzeichnet 68 Arbeiten an der Dateistruktur Werden Dateistrukturen geändert, so muss dies Subversion mitgeteilt werden, da Dateien sonst nicht unter Versionsverwaltung (Änderungen erst nach commit) Hinzufügen einer Datei oder eines Verzeichnisses (Verzeichnis automatisch rekursiv absteigend, ausschalten mit --nonrecursive), Daten müssen vorher existieren svn add neuedatei Löschen einer Datei oder eines Verzeichnisses svn delete wegdamit Kopieren einer Datei /eines Verzeichnisses (kein *) svn copy quelldatei zieldatei Verschieben einer Datei/ eines Vezeichnisses (kein *) svn move quelldatei neuerquelldateiname Verzeichnis anlegen svn mkdir verzeichnis (einige Befehle direkt auf Repository anwendbar) 69 Locking Setzen eines Locks (aktuell nur für Dateien möglich!) svn lock XStarter.java -m "Namen anpassen"»xstarter.java«gesperrt durch»administrator«. [anderer Nutzer] svn lock XStarter.java svn: warnung: Pfad»/MVC/source/src/de/kleuker/XStarter.java«ist bereits durch Benutzer»Administrator«im Dateisystem»g:/svnrepos/db«gesperrt Aufheben eines Locks, entweder mit commit (für alle Dateien eines angegebenen Verzeichnisses) oder svn unlock XStarter.java Erkennen eines Locks (z. B.) svn -v status --show-updates K 3 3 Administrator XStarter.java Neben dem Administrator kann jeder auch ein Lock löschen oder sogar stehlen (schlechter Projektstil) svn lock XStarter.java --force -m "Namen anpassen" evtl. aufräumen: svn cleanup (z. B. Problem, wenn ein Nutzer mehrmals gleiche Dateien auscheckt) 70

7 Nutzung von Properties Dateien und Verzeichnisse können Properties (Eigenschaften) als Paare Eigenschaftsname und Wert zugeordnet werden Properties stehen unter Versionskontrolle Es gibt Systemproperties (eigene dürfen deshalb nicht mit svn: beginnen Setzen (und ändern) von Properties svn propset lizenz 'free' XModel.java Lesen von Properties svn propget lizenz XModel.java svn proplist -v XModel.java Löschen von Properties svn propdel lizenz XModel.java Dateien ignorieren Generierte Dateien werden typischerweise nicht unter Versionskontrolle genommen, diese und Hilfsdateien wie ~*, können aus der Verwaltung ausgeschlossen werden es gibt zentrale Möglichkeit für Repository (haben wir nicht) Einstellung über Properties für Verzeichnisse (nicht absteigend gesetzt) svn propset svn:ignore -F ignore.txt kleuker ignore.txt ist Datei mit folgendem Inhalt: (Zeilenumbrüche beachten) Wenn doch alles gezeigt werden soll svn status --no-ignore? ignore.txt I bla.class I x.jar *.class *.jar Verzweigungen In großen Projekten möchte man häufig auf einem stabilen Stand eigene Experimente machen Typisch ist die Möglichkeit, Branches (Verzweigungen) ab einer bestimmten Version anzulegen (nicht Subversion) Subversion-Ansatz: Arbeitsversion als Kopie in Subversion erstellen (diese später synchronisieren und löschen) Direktes Kopieren auf Repository ist möglich svn copy file:///svnrepos/mvc/source file:///g:/svnrepos/mvc/branch -m"lokaler Branch" svn list -v file:///svnrepos/mvc 23 Administ Feb 11 15:09 branch/ 22 Administ Feb 11 15:06 source/ 73 Zusammenfassung: Typische Arbeitsschritte Am Anfang auschecken (einmal) oder aktualisieren checkout update evtl. Dateien erzeugen, löschen, verschieben add delete copy remove Änderungen analysieren status diff revert Änderungen durchführen commit Konflikte lösen update resolved Man beachte: Lokale Arbeitskopien können einfach gelöscht werden, dann neue Version auschecken 74

8 Weitere Konfigurationsmanagementaufgaben generell: Verwaltung aller Projektergebnisse, neben Quellcodes Dokumentation Arbeitsplatzstruktur (Dateistruktur des Projekts) Sicherung der benutzen Arbeitsumgebung, z. B. Kopie des verwendeten Betriebssystems Kopie des verwendeten Compilers Kopie der verwendeten Software- Entwicklungsumgebung eventuell alles mit Versionsnummer (z. B. bei Compilerwechsel) Erstellung von Sicherungskopien (wenn Server abbrennt, müssen fast aktuelle Arbeitsergebnisse erhalten bleiben; gibt Internetlösungen) muss jederzeit in der Lage sein, jedes Release in kurzer Zeit wieder herzustellen 75 Subversion und Eclipse = Subversive Subversion gut in Eclipse integriert Ansatz: Eclipseprojekt erstellen und dann in den Projektbaum in Subversion (nicht oberste Ebene) einbauen Generell dann Subversion-Nutzung bei Programmierung nur aus Eclipse heraus Shell, z. B. für Befehl svn status, zum Schauen ist erlaubt 76 Subversionverbindung in Eclipse Windows-Explorer+Subversion=TortoiseSVN 77 78

9 Übung (1/2) [Angaben für UNIX anpassen] 1. Neben dem eigentlichen Projekt-Repository, das Sie nur nutzen können, haben Sie die Möglichkeit, eigene Repositories anzulegen. Legen Sie zum Üben ein Repository unter z:/svnrepos an und spielen Sie ein Java-Projekt, genauer die *.java-dateien, ein. 2. Gehen Sie in ein anderes Verzeichnis, z. B. z:/tmp/svn1 und checken Sie das Projekt aus, probieren Sie die Befehle status, diff, commit und revert mehrfach mit kleinen Dateiänderungen aus. 3. Öffnen Sie eine zweite DOS-Box (cmd), gehen Sie in ein zweites Verzeichnis, z. B. /tmp/svn2 und checken Sie das Projekt aus. Ändern Sie in beiden DOS-Boxen eine Datei und versuchen Sie sie einzuchecken, nutzen Sie die Befehle status, update und resolved. Erzeugen Sie einmal eine Situation, in der Subversion die Dateien automatisch merged und eine Situation, in der Sie den Konflikt von Hand lösen müssen. 79 Übung (2/2) 4. Experimentieren Sie mit den Befehlen add, delete, copy. 5. Stellen Sie in einem Verzeichnis sicher, dass Dateien mit der Endung tmp nicht von Subversion verwaltet werden und prüfen Sie den Erfolg. 6. Setzen Sie und verändern Sie Eigenschaften (Properties) einer Datei. Was passiert, wenn zwei Nutzer unterschiedliche Änderungen machen? 7. Erzeugen Sie in Eclipse ein neues Java-Projekt und spielen Sie (nicht-versionierte) Dateien ein. Stellen Sie das Projekt unter Versionskontrolle und wiederholen Sie die Befehle ab Aufgabe 2 erneut (Sie müssen allerdings nicht erneut auschecken.) 8. Ergänzen Sie in Ihrem Repository ein neues Projekt von Eclipse aus. Ändern Sie eine Datei in Eclipse und außerhalb von Eclipse, checken Sie in Eclipse ein. 9. [Windows: Beschäftigen Sie sich mit den Nutzungsmöglichkeiten von TortoiseSVN] 80