3. Versions- und Konfigurationsmanagement Inkrementelle...

Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 47

3. Versions- und Konfigurationsmanagement

• Inkrementelle Entwicklungsschritte• Varianten der Versionskontrolle• Repository• Typischer Arbeitszyklus• Auflösung von Konflikten

Literatur:• [CFP07] B. Collins-Sussman, B. W. Fitzpatrick, C. M .

Pilato, Version Control with Subversion, [als PDF von Subversion-Webseite frei verfügbar]


Typischer Weg der Software-Entwicklung

Programmstück kodieren

Aufgabenteil auswählen

Programmstück testen

Korrektur-versuch

Einbau/Nutzung von Debuginformationen

kleine Lösungsvariante

große Lösungsvarianteläuft

nicht fertigfertig

kleiner Fehler

Fehlerunklar

kleine Überar-beitung

Umstruk-turierung


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 3V 4

V 5V 6

V 7

Inkrement 1

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)


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 n iemand

anderes diese Software bearbeiten (erhält die Situatio n 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 unterschiedl ichen

Programmstellen, wartende Entwickler, vergessenes Einchecken

• Realisierung von Repository sehr unterschiedlich lösba r (Datenbanksystem, Aufsatz auf Filesystem)

• Hinweis: Generell sollte das Einchecken mit einer Prüf ung verbunden sein


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 Ausche cken

zwischenzeitliche neue Version eingecheckt wurde, wen n ja, passiert Versionsabgleich, Konflikt muss gelöst werde n

• 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 s ehr kritische oder häufig genutzte Dateien konservativer An satz

• bisher Open Source: progressiv, kommerziell: konservativ


Ü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ängigkeite n 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.


Arc

hite

ktur

von

Sub

vers

ion

[CF

P07

]


Repository anlegen

• Hinweis: Sie werden bei der Arbeit mit Subversion typischerweise nur sehr wenige Befehle benötigen, hie r werden weitere Befehle vorgestellt, die das Üben auf dem eig enen Rechner ermöglichen. Dabei immer das lesenswerte freie B uch [CFP07] beachten

• Hinweis: Anlegen passiert durch zentralen Administra tor (FH-Regelung im Praktikum)

• G:\> svnadmin create /svnrepos

• hier wird u. a. eine Datenbank angelegt, diesen Ordner n ie von Hand bearbeiten

• svnadmin ist Administrationswerkzeug und wird von einfachen Nutzern nie genutzt

• Repository in Ordnerstruktur organisiert, diese Ordner werd en vom Nutzer selbst angelegt

• Man beachte, dass immer / genutzt werden muss


Einspielen der Daten

• Es werden lokale Daten in das Repository eingespielt• Zentrale Versionsmanagementaufgabe: Sinnvolle Datei struktur

für das Projekt anzulegen• Typischerweise werden generierbare Dateien (*.class) ni cht

unter Versionskontrolle genommen, evtl. sinnvoll, fer tige Releases vollständig einzuchecken (mit Executable), dieses aber nicht veränderbar

• Daten vor dem Einspielen in eine sinnvolle Repositor y-Strukturbringen

• G:\>svn import g:/antspiel/srcfile:///g:/svnrepos/MVC/source -m:"Ausgangsdaten"

• file steht für lokales Verzeichnis, hier normalerweise URL– http://svn.example.com:9834/repos

– file://localhost/svnrepos

– file:///g:/svnrepos oder "file:///g|/svnrepos"

• Hinweis: import Befehl wird nur einmal für Daten genut zt, danach zum Ändern immer die folgenden Befehle nutzen


Auschecken der Daten• Ansatz: Daten werden immer aus Repository in lokalen Ordner

kopiertG:\arbeit>svn checkout

file:///g:/svnrepos/MVC/source quelleA quelle/deA quelle/de/kleukerA quelle/de/kleuker/XView.javaA quelle/de/kleuker/XModel.javaA quelle/de/kleuker/XController.javaA quelle/de/kleuker/XStarter.javaA quelle/de/kleuker/XModelListener.javaAusgecheckt, Revision 1.G:\arbeit>dir quelle10.02.2007 17:28 <DIR> .10.02.2007 17:28 <DIR> ..10.02.2007 17:28 <DIR> .svn10.02.2007 17:28 <DIR> de

• .svn ist zentrales Verwaltungsverzeichnis zum Erkennen von Änderungen (verwaltet u. a. den Stand beim Auschecke n)

• Danach ist lokale Bearbeitung der Dateien möglich


Einchecken der Daten

• ausgecheckte Dateien beliebig veränderbar• löschen, kopieren und verschieben, an Subversion melde n• Mit commit können ganze Verzeichnisse eingecheckt werden,

man kann aber auch Dateien angeben (nur Neues wird ko piert), z. B. (ohne –mmit 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)


Datenunterschiede erkennen

• diff-Befehl zeigt zeilenweise Unterschiede (bei eigen er Arbeit, aber auch zwischen zwei Dateien), hier XStarter.java be arbeitetG:\arbeit\quelle\de\kleuker>svn diff XStarter.javaIndex: 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);

}}


Konfliktbearbeitung (1/5)

• Annahme: wir bearbeiten XStarter.java, diese Datei wurd e nach uns von anderem Entwickler zwischenzeitlich eingechec ktG:\arbeit\quelle\de\kleuker>svn commit

XStarter.java -m"Variablennamen angepasst"Sende XStarter.javasvn: übertragen fehlgeschlagen (Details folgen):svn: Out of date:

'/MVC/source/de/kleuker/XStarter.java' in transaction '6'

• Lösungsansatz: Zunächst eigene Dateien aktualisierenG:\arbeit\quelle\de\kleuker>svn updateG XStarter.javaAktualisiert zu Revision 5.

• U: selbst nicht bearbeitet, aber neue Version im Reposi tory• G: lokal und im Repository bearbeitet, von Subversion gelöst

(merGe) [???!!!]• C: selbst bearbeitet und im Repository bearbeitet, Sub version

hat keinen Lösungsvorschlag



• 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

}

}



• Bei erkanntem Konflikt auf Datei XStarter.java werden b ei update folgende Dateien angelegtG:\arbeit\quelle\de\kleuker>svn updateC XStarter.javaAktualisiert zu Revision 11.G:\arbeit\quelle\de\kleuker>dir XStarter.*11.02.2007 10:01 504 XStarter.java11.02.2007 10:01 306 XStarter.java.mine11.02.2007 10:01 296 XStarter.java.r1011.02.2007 10:01 313 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)



• Beispiel für Konfliktbeschreibung in Dateipackage de.kleuker;public class XStarter {

public static void main(String[] args) {XModel xmodel= new XModel();

<<<<<<< .minenew 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

}}



• 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 commiterfolgreich sein (theoretisch neues Problem möglich , falls zwischenzeitlich erneut neue Version eingespielt)

• Generell gilt, dass häufig auftretende Konflikte au f eine mangelnde Projektorganisation oder Kommunikation hindeuten


History-Informationen

• svn log-------------------------------------------------r4 | Administrator | 2007-02-11 09:59:52 +0100 (Sun, 11 Feb 2007) | 1 lineArrayStrukur-------------------------------------------------r3 | Administrator | 2007-02-10 19:12:26 +0100 (Sat, 10 Feb 2007) | 1 lineVariablennamen angepasst-------------------------------------------------r2 | Administrator | 2007-02-10 17:50:30 +0100 (Sat, 10 Feb 2007) | 1 linezwei Models und Views-------------------------------------------------r1 | Administrator | 2007-02-10 17:40:28 +0100 (Sat, 10 Feb 2007) | 1 lineAusgangsdaten-------------------------------------------------

• Möglichkeit, bestimmte Releases anzusehen: svn log –r 4:3

• Möglichkeit History einer Datei anzusehen (nur Release s mit Änderung angezeigt) : svn log XModel.java


Arbeit mit alten Versionen

• man kann aktuellen Stand mit Revisionen vergleichensvn diff –r3 XStarter.java

• man kann zwei Revisionen vergleichensvn diff –r2:3 XStarter.java

• man kann sich alten Stand ansehen (evtl. umlenken)svn cat –r2 XStarter.javasvn cat –r2 XStarter.java > analysedatei

• Inhalt des Repository ansehen (-v verbose häufiger nut zbar)G:\arbeit\quelle\de\kleuker>svn list -v

file:///g:/svnrepos/MVC/source/de/kleuker1 Administ 1566 Feb 10 17:16 XController.java1 Administ 1186 Feb 10 17:16 XModel.java1 Administ 90 Feb 10 17:16 XModelListener.java

11 Administ 313 Feb 11 09:59 XStarter.java4 Administ 1223 Feb 10 17:40 XView.java

• Auschecken einer alten Revisionsnummer (richtigen Ort beachten, danach normal mit commit und update bearbeit bar)svn checkout file:///g:/svnrepos/MVC/source/de -r3


Versionsnummern

• Versionsnummern einzelner Dateien werden bei commithochgezä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 wel cher Version letzte Änderung (formal alle in Version 19)G:\arbeit\quelle\de\kleuker>svn status -v11 11 Administrator .11 4 Administrator XView.java19 19 Administrator doku19 19 Administrator doku/comment.txt11 1 Administrator XModel.java11 1 Administrator XController.java11 11 Administrator XStarter.java11 1 Administrator XModelListener.java


Status abfragen

• Vor commit oder update immer sinnvoll, den aktuellen Arbeitsstatus abzufragen, gibt Informationen welche Änderungen durchgeführt wurden

Nicht versioniert, aber als extern gekennzeichnetX

Nicht unter Versionskontrolle, Ignorieren vereinbartI

Typ in Repository und Arbeitsbereich passt nicht~

Unter Versionskontrolle, fehlt aber (irrtümlich gelöscht )!

Befindet sich nicht unter Versionskontrolle (kein Prob lem)?

Soll ersetzt werden (gleicher Name, neuer Inhalt, replac e)R

Inhalt wurde verändert (modify)M

Soll gelöscht werden (delete)D

Steht in einem Konflikt, muss vor commit gelöst werdenC

Soll hinzugefügt werden (add)A


Arbeiten an der Dateistruktur

• Werden Dateistrukturen geändert, so muss dies Subversio n mitgeteilt werden, da Dateien sonst nicht unter Versionsverwaltung (Änderungen erst nach commit)

• Hinzufügen einer Datei oder eines Verzeichnisses (Verz eichnis automatisch rekursiv absteigend, ausschalten mit --non-recursive ), Daten müssen vorher existierensvn add neueDatei

• Löschen einer Datei oder eines Verzeichnissessvn delete wegDamit

• Kopieren einer Datei /eines Verzeichnisses (kein *)svn copy quelldatei zieldatei

• Verschieben einer Datei/ eines Vezeichnisses (kein *)svn move quelldatei neuerQuelldateiname

• Verzeichnis anlegensvn mkdir verzeichnis

• (einige Befehle direkt auf Repository anwendbar)


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.javasvn: 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) odersvn 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ösch en

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)


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 Propertiessvn propget lizenz XModel.javasvn proplist -v XModel.java

• Löschen von Propertiessvn propdel lizenz XModel.java


Dateien ignorieren

• Generierte Dateien werden typischerweise nicht unter Versionskontrolle genommen, diese und „Hilfsdateien“ w ie ~*, können aus der Verwaltung ausgeschlossen werden

• es gibt zentrale Möglichkeit für Repository (haben wi r nicht)• Einstellung über Properties für Verzeichnisse (nicht ab steigend

gesetzt) svn propset svn:ignore -F ignore.txt kleuker

• ignore.txt ist Datei mit folgendem Inhalt: (Zeilenumbrüche beachten)

• Wenn doch alles gezeigt werden sollsvn 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 stab ilen Stand eigene Experimente machen

• Typisch ist die Möglichkeit, Branches (Verzweigungen) ab einer bestimmten Version anzulegen (nicht Subversion)

• Subversion-Ansatz: Arbeitsversion als Kopie in Subversi on erstellen (diese später synchronisieren und löschen)

• Direktes Kopieren auf Repository ist möglichsvn copy file:///svnrepos/MVC/sourcefile:///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/


Zusammenfassung: Typische Arbeitsschritte

• Am Anfang auschecken (einmal) oder aktualisierencheckout update

• evtl. Dateien erzeugen, löschen, verschiebenadd delete copy remove

• Änderungen analysierenstatus diff revert

• Änderungen durchführencommit

• Konflikte lösenupdate resolved

• Man beachte: Lokale Arbeitskopien können einfach gelöscht werden, dann neue Version auschecken


Weitere Konfigurationsmanagementaufgaben

• generell: Verwaltung aller Projektergebnisse, neben Que llcodes– 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 bleibe n; gibt Internetlösungen)

• muss jederzeit in der Lage sein, jedes Release in ku rzer Zeit wieder herzustellen


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


Subversionverbindung in Eclipse


Windows-Explorer+Subversion=TortoiseSVN


Ü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 Re positoriesanzulegen. Legen Sie zum Üben ein Repository unter z:/svnrepos an und spielen Sie ein Java-Projekt, genau er die *.java-Dateien, ein.

2. Gehen Sie in ein anderes Verzeichnis, z. B. z:/tmp/s vn1 und checken Sie das Projekt aus, probieren Sie die Befehl e status, diff, commit und revert mehrfach mit kleinen Dateiänderun gen 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 Date i und versuchen Sie sie einzuchecken, nutzen Sie die Befeh le status, update und resolved. Erzeugen Sie einmal eine Situation, in der Subversion die Dateien automatisch mergedund eine Situation, in der Sie den Konflikt von Hand lösen müssen.


Übung (2/2)

4. Experimentieren Sie mit den Befehlen add, delete, c opy.5. Stellen Sie in einem Verzeichnis sicher, dass Date ien mit der

Endung tmp nicht von Subversion verwaltet werden und prüfen Sie den Erfolg.

6. Setzen Sie und verändern Sie Eigenschaften (Propert ies) einer Datei. Was passiert, wenn zwei Nutzer unterschiedlich e Ä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 Befehl e 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]

3. Versions- und Konfigurationsmanagement Inkrementelle...

Documents

Transcript of 3. Versions- und Konfigurationsmanagement Inkrementelle...