Transcript © Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn Versionsmanagement Software(technik)praktikum: Vorlesung 2: Versionsmanagement 11.03.2013 Versionsmanagement Motivation Ausgangslage  Softwareentwicklung ist Teamarbeit © Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität.

© Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn
Versionsmanagement
Software(technik)praktikum: Vorlesung 2: Versionsmanagement
11.03.2013
1
Versionsmanagement
Motivation
Ausgangslage
 Softwareentwicklung ist Teamarbeit
© Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn
 Viel (indirekte) Kommunikation nötig
 Entwicklungswissen muss dokumentiert wissen
 Software besteht aus vielen Dokumenten






Lastenheft
Pflichtenheft
Analyse- und Designdokument
Programmcode
Dokumentation
Handbuch
Software(technik)praktikum: Vorlesung 2: Versionsmanagement
11.03.2013
2
© Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn
Versionsmanagement
Motivation
Konsequenz
 Verschiedene Personen greifen (gleichzeitig) auf
Dokumente
 Oft bearbeiten verschiedene Personen gleichzeitig
(unabhängig voneinander) dasselbe Dokument
Software(technik)praktikum: Vorlesung 2: Versionsmanagement
11.03.2013
3
Versionsmanagement
Motivation
© Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn
Typische Probleme / Fragen
 Versionsmanagement
 Wo ist die aktuelle Version?
 Was ist die zuletzt lauffähige Version?
 Wo ist Implementierungsversion vom 01. April 2012?
• Und welche Dokumente beziehen sich auf diese Version?
 Welche Version wurde dem Kunden „Schäfer“ präsentiert?
 Änderungsmanagement
 Was hat sich seit letzter Woche geändert?
 Wer hat diese Änderung gemacht?
 Warum wurde diese Änderung gemacht?
Software(technik)praktikum: Vorlesung 2: Versionsmanagement
11.03.2013
4
Versionsmanagement
Motivation
© Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn
 Einfache Lösungen
 Austausch der
Dokumente via USBStick / Festplatte
 Austausch der
Dokumente via Mail
 Netzwerkfestplatte
 Konventionen und
Regeln werden im
Team definiert
Software(technik)praktikum: Vorlesung 2: Versionsmanagement
11.03.2013
5
Versionsmanagement
Motivation
© Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn
 Einfache „Lösungen“ erzeugen neue Problem




Konventionen und Regeln werden nicht eingehalten
Koordination ist aufwendig und führt zu Verzögerungen
Varianten und Konfigurationen werden von Hand verwaltet
Versions- und Änderungsfragen nicht bzw. nur schwer
beantwortbar
 Geistige Kapazität wird mit „Kleinkram“ verschwendet
 Fazit:
 Konventionen müssen technisch erzwungen werden!
Software(technik)praktikum: Vorlesung 2: Versionsmanagement
11.03.2013
6
Versionsmanagement
Motivation
© Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn
 Sinnvolle Lösung
 Versions- und Konfigurationsmanagementsysteme
 Lösen (bei vernünftiger Anwendung) alle genannten
Probleme (fast) ohne Zusatzaufwand
 Bieten sogar Zusatzleistungen (z.B. einfache
Datensicherung)
Software(technik)praktikum: Vorlesung 2: Versionsmanagement
11.03.2013
7
Versionsmanagement
Konzepte
Repository
© Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn
Dokumente in
hierarchischer
Struktur
Koordination der Zugriffe
und Modifikationen,
insbes. Wahrung der
Konsistenz
Versionsverwaltungssystem
Zugriff und Modifikation
von Dokumenten
Nutzer
Software(technik)praktikum: Vorlesung 2: Versionsmanagement
Nutzer
11.03.2013
8
Konsistenzmechanismen
© Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn
 Optimistische Mechanismen
 System erlaubt gleichzeitiges Bearbeiten des Dokuments durch
verschiedenen Personen
 System erkennt und integriert die Änderungen (Merging)
 Evtl. funktioniert das nicht automatisch; dann muss der Konflikt
manuell beseitigt werden
 Pessimistische Mechanismen
 System verbietet gleichzeitiges Bearbeiten des Dokuments durch
verschiedenen Personen (Sperrprotokolle)
 Beide Mechanismen haben Vor- und Nachteile
(hierzu später mehr)
Software(technik)praktikum: Vorlesung 2: Versionsmanagement
11.03.2013
9
Optimistischer Ansatz
© Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn
Repository
Versionsverwaltungssystem
Nutzer
Software(technik)praktikum: Vorlesung 2: Versionsmanagement
Lokale Kopien des
Repositories
(Arbeitsverzeichnis)
Nutzer
11.03.2013
1
Pessimistischer Ansatz
 Ablauf zur Bearbeitung einer Datei file.txt:
© Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn
checkout file.txt
< Bearbeitung der
Datei >
Zwischen checkout
und checkin kann kein
anderer Nutzer die
Datei verändern.
checkin file.txt
Genaue Syntax und Optionen
der Kommandos hängen vom
Versionsverwaltungssystem ab.
Software(technik)praktikum: Vorlesung 2: Versionsmanagement
11.03.2013
1
Optimistischer Ansatz
© Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn
 update - Nutzer aktualisiert seine lokale Kopie des
Repositories
 commit - Nutzer übergibt seine lokale Kopie an das
Repository (Versionsnummer wird inkrementiert)
 Ändern der lokalen Kopie durch Nutzer jederzeit erlaubt
(es gibt keine Sperren)
 update und commit sind (nahezu) jederzeit erlaubt
Genaue Syntax und Optionen
der Kommandos hängen vom
Versionsverwaltungssystem ab.
Software(technik)praktikum: Vorlesung 2: Versionsmanagement
11.03.2013
1
Optimistischer Ansatz
Mischen (Merge): Szenario 1
© Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn
file.txt
Änderungen im Repository
(durch commit anderer Benutzer)
Software(technik)praktikum: Vorlesung 2: Versionsmanagement
file.txt
Änderungen im
Arbeitsverzeichnis
11.03.2013
1
Optimistischer Ansatz
Mischen (Merge): Szenario 1
file.txt
file.txt
© Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn
update
(+ ggf. merge)
Merge:
Änderungen aus dem
Repository (seit der
letzten Aktualisierung)
und der Änderungen
im lokalen Verzeichnis
Änderungen im
Repository
Software(technik)praktikum: Vorlesung 2:
2 Versionsmanagement
Aktualisierte Version im
Arbeitsverzeichnis
11.03.2013
14
1
Optimistischer Ansatz
Mischen (Merge): Szenario 1
© Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn
file.txt
Bei gängigen Systemen
funktioniert das erstmal
nur mit Text-Dateien (z.B.
.java oder .tex)
file.txt
update
Änderungen im
Repository
Software(technik)praktikum: Vorlesung 2: Versionsmanagement
Aktualisierte Version im
Arbeitsverzeichnis
11.03.2013
1
Optimistischer Ansatz
Mischen (Merge): Szenario 2
© Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn
file.txt
Änderungen im
Repository
Software(technik)praktikum: Vorlesung 2: Versionsmanagement
file.txt
Änderungen im
Arbeitsverzeichnis
11.03.2013
1
Optimistischer Ansatz
Mischen (Merge): Szenario 2
© Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn
file.txt
Konflikt
file.txt
update
Änderungen im
Repository
Software(technik)praktikum: Vorlesung 2: Versionsmanagement
Änderungen im
Arbeitsverzeichnis
11.03.2013
1
Optimistischer Ansatz
Konflikte
© Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn
 Konflikte werden in der Datei im Arbeitsverzeichnis
markiert:
<<<<<<
Änderung 1
-----Änderung 2
>>>>>>
 Konflikte müssen vom Benutzer in seiner Arbeitskopie
von Hand korrigiert werden.
 Hinweis: Konflikte entstehen nur Arbeitsverzeichnis
Software(technik)praktikum: Vorlesung 2: Versionsmanagement
11.03.2013
1
Optimistischer Ansatz
Mergen binärer Dateien
 Für Textdateien existieren gute Merge-Algorithmen
 Java, Latex, ... somit gut vergleichbar und mergebar
© Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn
 Für binäre Dateien müssen separate Merge-Algorithmen
vorhanden sein
 Beispiel: MS Word-Dokument
 Word bietet jedoch intern Vergleichs- und Mergeoptionen
 Hinweis: In Versionsverwaltungssystemen kann man
angeben, ob eine Datei binär ist
Software(technik)praktikum: Vorlesung 2: Versionsmanagement
11.03.2013
1
Optimistischer Ansatz
Frage bzgl. Commit
© Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn
 Frage: Was passiert, wenn der Nutzer ein commit
durchführt, und dabei Änderungen im Repository noch
nicht in sein Arbeitsverzeichnis übernommen hat?
 Antwort:
 Wird durch Repository-Client verboten.
 Client fordert, dass erst update ausgeführt wird
 Commit erst danach möglich
• Commit nur möglich, wenn lokales Repository konfliktfrei ist
Software(technik)praktikum: Vorlesung 2: Versionsmanagement
11.03.2013
2
Optimistischer Ansatz
Commit-Unterbindung
© Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn
v100
Versionsverwaltungssystem
v100
Software(technik)praktikum: Vorlesung 2: Versionsmanagement
v100
11.03.2013
2
Optimistischer Ansatz
Commit-Unterbindung
© Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn
v100
Versionsverwaltungssystem
v100*
Software(technik)praktikum: Vorlesung 2: Versionsmanagement
v100*
v100
11.03.2013
2
Optimistischer Ansatz
Commit-Unterbindung
© Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn
> commit
up-to-date
check failed
> commit
v101
Versionsverwaltungssystem
v100*
Software(technik)praktikum: Vorlesung 2: Versionsmanagement
v101
11.03.2013
2
Optimistischer Ansatz
Commit-Unterbindung
© Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn
> commit
up-to-date
check failed
> commit
v101
> update
M file.txt
Versionsverwaltungssystem
v100*
v101*
Software(technik)praktikum: Vorlesung 2: Versionsmanagement
v101
11.03.2013
2
Optimistischer Ansatz
Commit-Unterbindung
© Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn
> commit
up-to-date
check failed
> update
M file.txt
> commit
v101*
v102
Software(technik)praktikum: Vorlesung 2: Versionsmanagement
> commit
v102
v101
Versionsverwaltungssystem
v101
11.03.2013
2
© Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn
Unterstützung für Versionsmanagement in Eclipse
Software(technik)praktikum: Vorlesung 2:
2 Versionsmanagement
11.03.2013
26
2
Vergleich: Pessimistisch vs
Optimistisch
 Pessimistische Mechanismen
© Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn
++ keine Konflikte
-- kein gleichzeitiges Arbeiten an demselben Dokument
(bei großen Dateien behindert es die Teamarbeit)
-- Dateien können unabsichtlich lange gesperrt sein
 Optimistische Mechanismen
-- Konflikte (oft vermeidbar bei sehr guter Absprache)
++ gleichzeitiges Arbeiten an Dokumenten möglich
 Für typische Softwareprojekte (große und verteilt
arbeitende Teams) haben sich die optimistischen
Mechanismen als zweckmäßiger erwiesen
Software(technik)praktikum: Vorlesung 2: Versionsmanagement
11.03.2013
2
Versionierungsart
Repository-Versionierung
© Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn
Repository-Versionierung
 Je commit gibt es eine neue Repository-Nummer
 Head ist neueste Repository-Version
<<changed>> <<added>>
>>commit
V4
Main.java
Appl.java
<<added>>
>>commit
V3
main.html
<<added>>
>>commit
V2
>>commit
V1
<<added>>
index.html
Main.java
Software(technik)praktikum: Vorlesung 2: Versionsmanagement
11.03.2013
2
Versionierungsart
Dateiversionierung
© Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn
Dateiversionierung
 Jede Datei hat ihre eigene Version
 Je Commit werden Versionsnummern der Dateien inkrementiert
 Konfiguration: Menge von Dateiversionen
Konfiguration:
 Heute (head)
 Release
V1.1
V1
Main.java
Software(technik)praktikum: Vorlesung 2: Versionsmanagement
V2.0
V1.2
V1.2
V1.1
V1.1
V1
Appl.java
V1
index.html
V1
main.html
11.03.2013
2
Weitere Features von
Versionsmanagementsystemen
 Zugriff auf alte Versionen
 Alte Versionen sind jederzeit zugreifbar (wichtiger
Unterschied zu simpler Netzwerkfestplatte)
© Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn
 Versionsvergleich
 Differenz der Dateien markiert Änderungen
 Branching
 Alternative Entwicklungszweige ermöglichen das
Versionieren von Varianten (z.B. Implementierung eines
alternativen Benutzerinterfaces)
 Tagging
 Versionen markieren (z.B. Release 1.0)
Software(technik)praktikum: Vorlesung 2: Versionsmanagement
11.03.2013
3
Weitere Features von
Versionsmanagementsystemen
 Kommitkommentar
 Mit jedem commit kann (und sollte) man in einem kurzen
Kommentar angeben, welche Änderungen vorgenommen
wurden
© Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn
 Mailbenachrichtung
 Bei Änderungen von Dateien können automatisch
Nachrichten an andere Nutzer verschickt werden
 Blame-Analyse
 Man kann für jede Datei feststellen, welche Zeile von
welchem Nutzer zuletzt bearbeitet wurde (blame)
 Verknüpfung mit Ticketmanagementsystem
 Tickets (z.B. Trac) für Bug-Reports und Features-Requests
können sich auf Versionsnummern beziehen
Software(technik)praktikum: Vorlesung 2: Versionsmanagement
11.03.2013
3
Inhalt für das Repository
© Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn
 Welche Dokumente und Dateien gehören ins Repository?
 Alle Dokumente und Dateien, die zur Software und ihrem
Entwicklungsprozess gehören und nicht automatisch aus
den anderen Dateien oder Dokumenten generiert werden
können
 z.B. Keine temporären Latex-Dateien *.aux, *.bbl, ...
 …vermeiden, trotzdem Kopien anzulegen!
 (Kopie (1) von …, Kopie (2) von …, Kopie (3) von …)
Software(technik)praktikum: Vorlesung 2: Versionsmanagement
11.03.2013
3
Praktikum: SVN
© Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn
 Im Praktikum nutzen wir optimistische Mechanismen
 Konkret: Subversion (SVN)
 Wird eingesetzt bei Apache,
SourceForge, Google Code, ...
 Features:




Commit-Kommentare
Mailbenachrichtung bei jedem Checkin
Blame-Analyse
Verknüpfbar mit Ticketmanagementsystem
(z.B. Trac)
 Viele SVN-Clients, u.a.
• Subclipse und Subversive für Eclipse
• TortoiseSVN
• Integriert sich in Windows-Explorer
Software(technik)praktikum: Vorlesung 2: Versionsmanagement
11.03.2013
3
Praktikum: SVN
© Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn
 SVN unterstützt nur Repository-Versionierung
 SVN unterscheidet zwischen
 trunk (Stamm): Standardentwicklungspfad
 tags (Markierung): Meilensteine, Abgaben, Release, ...
 branch (Verzweigung): temporäre Pfade für Varianten
Zeit
http://commons.wikimedia.org/wiki/File:Subversion_project_visualization.svg
Software(technik)praktikum: Vorlesung 2: Versionsmanagement
11.03.2013
3
Zusammenfassung
 Versionsmanagementsysteme erleichtern das
gemeinsame Arbeiten an Dokumenten und Dateien
© Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn
 Änderungen sind nachverfolgbar
 Alte Versionen sind zugreifbar
 Im Praktikum nutzen wir das optimistische
Verfahren SVN
 Üben Sie das Arbeiten mit SVN
 Nutzen Sie unser Tutorial auf der Webseite.
 Nutzen Sie die Tutorials im Web
Software(technik)praktikum: Vorlesung 2: Versionsmanagement
11.03.2013
3