© Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn Versionsmanagement 1 Software(technik)praktikum: Vorlesung 2: Versionsmanagement11.03.2013

© F

achg

ebie

t S

oftw

aret

echn

ik,

Hei

nz N

ixdo

rf I

nstit

ut,

Uni

vers

ität

Pad

erbo

rn

1

Versionsmanagement

Software(technik)praktikum: Vorlesung 2: Versionsmanagement 11.03.2013

© F

achg

ebie

t S

oftw

aret

echn

ik,

Hei

nz N

ixdo

rf I

nstit

ut,

Uni

vers

ität

Pad

erbo

rn

Versionsmanagement Motivation

Ausgangslage Softwareentwicklung ist Teamarbeit

Viel (indirekte) Kommunikation nötig Entwicklungswissen muss dokumentiert wissen

Software besteht aus vielen Dokumenten Lastenheft Pflichtenheft Analyse- und Designdokument Programmcode Dokumentation Handbuch

11.03.2013Software(technik)praktikum: Vorlesung 2: Versionsmanagement 2

© F

achg

ebie

t S

oftw

aret

echn

ik,

Hei

nz N

ixdo

rf I

nstit

ut,

Uni

vers

ität

Pad

erbo

rn


Konsequenz Verschiedene Personen greifen (gleichzeitig) auf

Dokumente Oft bearbeiten verschiedene Personen gleichzeitig

(unabhängig voneinander) dasselbe Dokument


© F

achg

ebie

t S

oftw

aret

echn

ik,

Hei

nz N

ixdo

rf I

nstit

ut,

Uni

vers

ität

Pad

erbo

rn


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?


© F

achg

ebie

t S

oftw

aret

echn

ik,

Hei

nz N

ixdo

rf I

nstit

ut,

Uni

vers

ität

Pad

erbo

rn


Einfache Lösungen Austausch der

Dokumente via USB-Stick / Festplatte

Austausch der Dokumente via Mail

Netzwerkfestplatte

Konventionen und Regeln werden im Team definiert


© F

achg

ebie

t S

oftw

aret

echn

ik,

Hei

nz N

ixdo

rf I

nstit

ut,

Uni

vers

ität

Pad

erbo

rn


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!


© F

achg

ebie

t S

oftw

aret

echn

ik,

Hei

nz N

ixdo

rf I

nstit

ut,

Uni

vers

ität

Pad

erbo

rn


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)


© F

achg

ebie

t S

oftw

aret

echn

ik,

Hei

nz N

ixdo

rf I

nstit

ut,

Uni

vers

ität

Pad

erbo

rn

Versionsmanagement Konzepte

Versions-verwaltungs-

system

Dokumente in hierarchischer Struktur

Zugriff und Modifikation von Dokumenten

Koordination der Zugriffe und Modifikationen, insbes. Wahrung der Konsistenz

Nutzer Nutzer

Repository


© F

achg

ebie

t S

oftw

aret

echn

ik,

Hei

nz N

ixdo

rf I

nstit

ut,

Uni

vers

ität

Pad

erbo

rn

Konsistenzmechanismen

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)


© F

achg

ebie

t S

oftw

aret

echn

ik,

Hei

nz N

ixdo

rf I

nstit

ut,

Uni

vers

ität

Pad

erbo

rn

Optimistischer Ansatz

Versions-verwaltungs-system Lokale Kopien des

Repositories (Arbeitsverzeichnis)

Nutzer

Repository

Nutzer11.03.2013Software(technik)praktikum: Vorlesung 2: Versionsmanagement 1

0

© F

achg

ebie

t S

oftw

aret

echn

ik,

Hei

nz N

ixdo

rf I

nstit

ut,

Uni

vers

ität

Pad

erbo

rn

Pessimistischer Ansatz

Ablauf zur Bearbeitung einer Datei file.txt:

checkout file.txt

< Bearbeitung der Datei >

checkin file.txt

Zwischen checkout und checkin kann kein anderer Nutzer die Datei verändern.

Genaue Syntax und Optionen der Kommandos hängen vom Versionsverwaltungssystem ab.


© F

achg

ebie

t S

oftw

aret

echn

ik,

Hei

nz N

ixdo

rf I

nstit

ut,

Uni

vers

ität

Pad

erbo

rn

Optimistischer Ansatz

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.


© F

achg

ebie

t S

oftw

aret

echn

ik,

Hei

nz N

ixdo

rf I

nstit

ut,

Uni

vers

ität

Pad

erbo

rn

Optimistischer AnsatzMischen (Merge): Szenario 1

file.txt file.txt

Änderungen im Repository(durch commit anderer Benutzer)

Änderungen im Arbeitsverzeichnis

file.txt


© F

achg

ebie

t S

oftw

aret

echn

ik,

Hei

nz N

ixdo

rf I

nstit

ut,

Uni

vers

ität

Pad

erbo

rn


14Software(technik)praktikum: Vorlesung 2

file.txt file.txt

Änderungen im Repository

Aktualisierte Version imArbeitsverzeichnis

update

(+ ggf. merge)

Merge: Änderungen aus dem Repository (seit der letzten Aktualisierung) und der Änderungen im lokalen Verzeichnis


© F

achg

ebie

t S

oftw

aret

echn

ik,

Hei

nz N

ixdo

rf I

nstit

ut,

Uni

vers

ität

Pad

erbo

rn


file.txt file.txt


Aktualisierte Version imArbeitsverzeichnis

update

Bei gängigen Systemen funktioniert das erstmal nur mit Text-Dateien (z.B. .java oder .tex)


© F

achg

ebie

t S

oftw

aret

echn

ik,

Hei

nz N

ixdo

rf I

nstit

ut,

Uni

vers

ität

Pad

erbo

rn


file.txt file.txt



file.txt


© F

achg

ebie

t S

oftw

aret

echn

ik,

Hei

nz N

ixdo

rf I

nstit

ut,

Uni

vers

ität

Pad

erbo

rn


file.txt file.txt



file.txt

update

Konflikt


© F

achg

ebie

t S

oftw

aret

echn

ik,

Hei

nz N

ixdo

rf I

nstit

ut,

Uni

vers

ität

Pad

erbo

rn

Optimistischer AnsatzKonflikte

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


© F

achg

ebie

t S

oftw

aret

echn

ik,

Hei

nz N

ixdo

rf I

nstit

ut,

Uni

vers

ität

Pad

erbo

rn

Optimistischer AnsatzMergen binärer Dateien

Für Textdateien existieren gute Merge-Algorithmen Java, Latex, ... somit gut vergleichbar und mergebar

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


© F

achg

ebie

t S

oftw

aret

echn

ik,

Hei

nz N

ixdo

rf I

nstit

ut,

Uni

vers

ität

Pad

erbo

rn

Optimistischer Ansatz Frage bzgl. Commit

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


© F

achg

ebie

t S

oftw

aret

echn

ik,

Hei

nz N

ixdo

rf I

nstit

ut,

Uni

vers

ität

Pad

erbo

rn

Optimistischer Ansatz Commit-Unterbindung

v100

Versions-verwaltungs-system

v100 v100


© F

achg

ebie

t S

oftw

aret

echn

ik,

Hei

nz N

ixdo

rf I

nstit

ut,

Uni

vers

ität

Pad

erbo

rn


v100


v100* v100*v100


© F

achg

ebie

t S

oftw

aret

echn

ik,

Hei

nz N

ixdo

rf I

nstit

ut,

Uni

vers

ität

Pad

erbo

rn


v101


v100* v101

> commit > commit

up-to-datecheck failed


© F

achg

ebie

t S

oftw

aret

echn

ik,

Hei

nz N

ixdo

rf I

nstit

ut,

Uni

vers

ität

Pad

erbo

rn


v101


v101* v101

> commit> commit


> update

M file.txt

v100*


© F

achg

ebie

t S

oftw

aret

echn

ik,

Hei

nz N

ixdo

rf I

nstit

ut,

Uni

vers

ität

Pad

erbo

rn


v102


v102 v101

> commit> commit


> update

M file.txt

> commit

v101

v101*


© F

achg

ebie

t S

oftw

aret

echn

ik,

Hei

nz N

ixdo

rf I

nstit

ut,

Uni

vers

ität

Pad

erbo

rn

Unterstützung für Versions-management in Eclipse

26Software(technik)praktikum: Vorlesung 2 11.03.2013Software(technik)praktikum: Vorlesung 2: Versionsmanagement 26

© F

achg

ebie

t S

oftw

aret

echn

ik,

Hei

nz N

ixdo

rf I

nstit

ut,

Uni

vers

ität

Pad

erbo

rn

Vergleich: Pessimistisch vs Optimistisch

Pessimistische Mechanismen++ 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


© F

achg

ebie

t S

oftw

aret

echn

ik,

Hei

nz N

ixdo

rf I

nstit

ut,

Uni

vers

ität

Pad

erbo

rn

28

Software(technik)praktikum: Vorlesung 2: Versionsmanagement

VersionierungsartRepository-Versionierung

Repository-Versionierung Je commit gibt es eine neue Repository-Nummer Head ist neueste Repository-Version

11.03.2013

Main.java

index.html

main.html

V1

V2

V3

V4 Main.java Appl.java

>>commit

>>commit

>>commit

>>commit

<<added>>

<<added>>

<<added>>

<<added>><<changed>>

© F

achg

ebie

t S

oftw

aret

echn

ik,

Hei

nz N

ixdo

rf I

nstit

ut,

Uni

vers

ität

Pad

erbo

rn

Versionierungsart Dateiversionierung

Dateiversionierung Jede Datei hat ihre eigene Version Je Commit werden Versionsnummern der Dateien inkrementiert Konfiguration: Menge von Dateiversionen

Main.java Appl.java index.html main.html

V1

V2.0 V1.1

V1.2

V1

V1.1

V1 V1

V1.1

V1.2Konfiguration: Heute (head) Release


© F

achg

ebie

t S

oftw

aret

echn

ik,

Hei

nz N

ixdo

rf I

nstit

ut,

Uni

vers

ität

Pad

erbo

rn

Weitere Features von Versionsmanagementsystemen

Zugriff auf alte Versionen Alte Versionen sind jederzeit zugreifbar (wichtiger

Unterschied zu simpler Netzwerkfestplatte) 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)


© F

achg

ebie

t S

oftw

aret

echn

ik,

Hei

nz N

ixdo

rf I

nstit

ut,

Uni

vers

ität

Pad

erbo

rn

Weitere Features von Versionsmanagementsystemen

Kommitkommentar Mit jedem commit kann (und sollte) man in einem kurzen

Kommentar angeben, welche Änderungen vorgenommen wurden

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


© F

achg

ebie

t S

oftw

aret

echn

ik,

Hei

nz N

ixdo

rf I

nstit

ut,

Uni

vers

ität

Pad

erbo

rn

Inhalt für das Repository

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 …)


© F

achg

ebie

t S

oftw

aret

echn

ik,

Hei

nz N

ixdo

rf I

nstit

ut,

Uni

vers

ität

Pad

erbo

rn

Praktikum: SVN

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


© F

achg

ebie

t S

oftw

aret

echn

ik,

Hei

nz N

ixdo

rf I

nstit

ut,

Uni

vers

ität

Pad

erbo

rn

Praktikum: SVN

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

© F

achg

ebie

t S

oftw

aret

echn

ik,

Hei

nz N

ixdo

rf I

nstit

ut,

Uni

vers

ität

Pad

erbo

rn

Zusammenfassung

Versionsmanagementsysteme erleichtern das gemeinsame Arbeiten an Dokumenten und Dateien Ä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


Documents

© Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn Versionsmanagement 1 Software(technik)praktikum: Vorlesung 2: Versionsmanagement11.03.2013