© 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.
Download
Report
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