Versionsverwaltung von Softwareartefakten - uni-marburg.de · –Diese Situation wird Konflikt genannt. •Lassen sich zwei Dokumente immer mischen? –Die Unterschiede zwischen zwei

Versionsverwaltung von

Softwareartefakten

Dr. Thorsten Arendt

Marburg, 05. November 2015

Überblick

• Warum ist die Versionsverwaltung von Softwareartefakten wichtig?

• Wie verwaltet man Softwareartefakte?

– Versionskontrolle für Anforderungsdokumente, Modelle, Code,

Testdateien, Dokumentationen, etc.

– Möglichst unabhängiges Arbeiten im Team

– Wie erhält man konsistente Konfigurationen?

• Einführung in Versionsverwaltungswerkzeuge

– Subversion (SVN): Zentrale Verwaltung von Dateien und Ordnern

– Git: Verteilte Versionsverwaltung

2 Software-Evolution WS 2015/2016

Versionsprobleme

• Vermeide Fragen und Probleme wie diese:

– Welche ist die neueste Version eines Softwaresystems?

– Ich kann eine ältere Version der Software nicht finden.

– Ich kann eine bestimmte Version des Softwaresystems nicht

erstellen, weil bestimmte Dateien fehlen.

– Eine gerade erstellte Datei wurde von einer älteren Version

überschrieben, weil

• gerade nicht aufgepasst wurde.

• sie parallel geändert wurde.


Gründe für Versionsprobleme

• Software ist einfach zu ändern.

• Mehrere Personen dürfen dieselben Artefakte ändern, eventuell

sogar zur gleichen Zeit.

• Es ist einfach,

– Inkonsistenzen zu erzeugen.

– schwer erkennbare Fehler zu erzeugen.

• Beispiele:

– Zwei Entwickler führen unabhängig voneinander Änderungen an

verschiedenen Klassen durch. Diese passen nicht zueinander.

– Source Code geändert: Binärcode, Design, Dokumentation und Tests

werden inkonsistent.


Motivation für klassische Versionsverwaltung

• Ein Versionsverwaltungssystem soll das gemeinschaftliche Arbeiten

an Dokumenten ermöglichen.

• Hauptproblem:

– Wie ermöglicht das Versionsverwaltungssystem den Nutzern Zugang zu

gemeinsamen Dokumenten, ohne versehentlich Informationen zu

löschen?

• Ansatz:

– Alle gemeinschaftlich genutzten Dokumente werden in einem Repository

(einem speziellen Datenbehälter) verwaltet.

– Die Nutzer bekommen Lese- bzw. Schreibzugang zu Dokumenten im

Repository.

– Werkzeuge: CVS, SVN, Git, etc.


• Zwei Nutzer (Harry und Sally)

entscheiden sich, an

demselben Dokument (A) zu

arbeiten.

• Beide führen verschiedene

Änderungen an ihren lokalen

Versionen des Dokuments

durch.

• Die lokalen Versionen werden

nacheinander in das

Repository geschrieben.

• Sally überschreibt dadurch

eventuell Änderungen von

Harry.

[Version Control with Subversion]


Das Problem

• Harry sperrt das

Dokument und arbeitet

lokal daran.

• Sally möchte das

Dokument lesen, es ist

aber gesperrt.

• Harry schreibt sein

geändertes Dokument ins

Repository und entsperrt

es.

• Sally kann nun das

Dokument lesen und für

andere sperren.



Problemlösung 1: Sperren von Dokumenten

• Administrative Probleme

– Gesperrte Dokumente werden vergessen zu entsperren. Andere

Nutzer kommen an die gesperrten Dokumente nicht ran.

• Unnötige Sequentialisierung der Arbeit

– Wenn zwei Nutzer ein Dokument an verschiedenen Stellen

ändern möchten, könnten sie dies auch gleichzeitig tun.

• Falsches Gefühl von Sicherheit

– Zwei Nutzer arbeiten getrennt auf den Dokumenten A und B.

Was passiert, wenn A von B abhängig ist? A und B passen nicht

mehr zusammen. Die Nutzer müssen dieses Problem

diskutieren.


Wie gut ist Problemlösung 1?

• Harry und Sally kopieren

das Dokument in ihre

lokalen Ordner.

• Beide arbeiten

unabhängig daran.

• Sally schreibt als Erste

das Dokument in das

Repository zurück.

• Harry kann das

Dokument nicht

zurückschreiben:

– „out of date“



Problemlösung 2: Mischen von Dokumenten

• Harry vergleicht seine

lokale Version mit der

aktuellen Version im

Repository.

• Beide Versionen werden

gemischt.

• Die neue (gemischte)

Version wird

zurückgeschrieben.

• Die neue Version kann

ausgelesen werden.




• Ein Dokument liegt in zwei Versionen vor.

– Die Änderungen eines Nutzers überlappen sich mit den Änderungen des zweiten Nutzers.

– Diese Situation wird Konflikt genannt.

• Lassen sich zwei Dokumente immer mischen?

– Die Unterschiede zwischen zwei Versionen lassen sich durch Werkzeuge anzeigen.

– Ein Nutzer (eventuell in Absprache mit dem zweiten Nutzer) entscheidet jeden einzelnen Konflikt.


Wie gut ist Problemlösung 2?



Zwei unabhängige Dokumente

werden gemischt. Dazu müssen

Korrespondenzen gefunden werden.

Ausgehend von einer Original-

version werden Differenzen

berechnet und gemischt.

Zwei-Wege-Mischen Drei-Wege-Mischen

• Softwareartefakte

sind in Ordnern

gegliedert.

• Versionsverwaltung

sollte nicht nur die

Dateien, sondern

auch die Ordner

verwalten.


Revisionen


Revision: Ein Zustand der zu verwaltenden Softwareartefakte

• Open Source Software

– 2000 von CollabNet entwickelt

– Seit 2009 bei Apache

• Features

– Versionierung von Ordnern und Dateien

– Auch das Umbenennen, Erzeugen und Löschen von Ordnern werden festgehalten.

– Sammlung von Änderungen wird als Transaktion verwaltet.

• Subversion für Eclipse

– Subclipse

– Subversive

• Subversion im Windows Datei-Explorer

– TortoiseSVN


Subversion (SVN)

• Software für verteilte Versionsverwaltung ohne zentralen Server

• Lokale Kopie des gesamten Repositories– Lokale Funktionalität ähnlich wie bei SVN

• Neue Features:– Versionen als Schnappschüsse eines Mini-Dateisystems

– Nichtlineare Entwicklung: einfaches Branching und Merging

– Datenabgleich zwischen verschiedenen Repositories möglich

• Werkzeuge:– Git Cloud Hosting: GitHub, GitLab, BitBucket, etc.

– Git Client: z.B. Atlassian SourceTree

– Git in Eclipse: EGit

– Git im Datei-Explorer: TortoiseGit


Git

Ein zentrales Repository für die

Arbeitsgruppe

– z.B. in der Cloud

[Atlassian SourceTree]


Aufbau eines zentralen Repository

[Bitbucket]

Lokale Arbeitsbereiche oder

lokale Repositories

• Eclipse Plugin: EGit

• Wechsel zur Git Repository Perspective

• Versionsverwaltung starten:

– Neues Git Repository anlegen mit Create

– Vorhandenes Repository kopieren mit Clone

– Vorhandenes Projekt in ein neues Repository legen: Team → Share Project

• Lokales Arbeiten in der Java-Perspektive.

– Git-Befehle unter Team → …


Git in Eclipse

[EGit]

• Um eine lokale Kopie des

entfernten Repository zu erstellen

• Auswahl einzelner Branches

• Angabe des lokalen Ordners


Clone eines Git Repository

[EGit]

• Push lädt einen lokalen

Branch oder eine Reihe

von Commits in ein

entferntes Repository.

– zum Veröffentlichen

von Beiträgen

• Pull lädt einen Branch

aus einem entfernten

Repository.


Laden lokaler Sourcen


Entferntes Repository

• Start der Versionierung:

– git add <filename>

• Datei auschecken:

– git checkout <filename>

• Versionierungsabfragen:

– git status (Status der Dateien)

– git log (Historie)

• Änderungsanzeige (vor commit)

– git diff

• Datei einchecken:

– git add <filename> ( Index)

git commit (indizierte Dateien)

– git commit –a <filename>

• Datei aus Repository löschen:

– git rm <filename>


Typische Git-Befehle auf lokalem Repository

• Version: Mini-Dateisystem in einem Zustand

• Unveränderte Dateien werden nicht kopiert.

• Git fügt nur Daten hinzu.

[ProGit]


Versionen als Schnappschüsse

• Ein zentrales Repository

• Lokales Mischen

– Beispiel: John kann nach Jessica kein Push ausführen. Er muss ihre Änderungen holen und lokal mischen.

– Das Holen von Änderungen (fetch, pull) führt zu einem neuen Branch.

– Das lokale Mischen (merge) führt zwei Branches zusammen.


Austausch zwischen Repositories: Ein

Beispielablauf

[ProGit]

• Gründe für mehrere

Zweige:

– Verschiedene Alternativen

gleichzeitig ausprobieren

– Normales „Geschäft“ und

größerer Evolutionsschritt

– Releases

• Unterscheidung in den

zentralen Branch und

weiteren Branches

Original

1. Branch

2. Branch

3. Branch


Verschiedene Revisionszweige (Branches)

Commit-Objekt

• Referenz auf einen

Schnappschuss

• Commit-Objekte zeigen

jeweils auf das vorige.

• Weitere Einträge sind

– der Autor,

– der Committer und

– die Commit-Message


Branches (1)

[ProGit]

• Der Default-Branch

heisst „master“.

• Zwei Branches

können auf denselben

Schnappschuss

verweisen.

• Der aktuelle Branch

heisst „HEAD“.


Branches (2)

• Die Historie läuft

auseinander:

Beispiel:

– „master“-Branch

– „testing“-Branch

• Der Nutzer kann…

– beliebig zwischen den

Branches wechseln.

– die Branches

zusammenführen


Branches (3)

• Merging von

aufeinander-

folgenden

Commits /

Schnappschüssen

• Fast Forward


Merging (1)

• Merging von

auseinander

laufenden

Commits /

Schnappschüssen

• 3-Wege-Mischen

– Ein neuer

Schnappschuss

entsteht

• Merge Commit

– Mehrere

Vorgänger


Merging (2)

• Alternatives

Merging von

aufeinander-

folgenden Commits /

Schnappschüssen

• Verwendung eines

Patches des einen

auf den anderen

Schnappschuss

• Anschließender Fast

Forward


Rebasing


Beispiel für

Branches

http://nvie.com/posts/a-successful-git-branching-model/

• Entwicklerteam arbeitet auf dem Hauptzweig.

• Erstellung eines Release-Zweigs

– Z.B.: branches/1.0

• Team arbeitet parallel:

– Intensives Testen der Release-Version

– Neue Features in der Hauptversion (für Version 2.0)

• Der Release-Zweig bekommt ein Tag und wird releast.

– Tag: ein Schnappschuss des Projekts

– Z.B: /tags/1.0.0

• Der Release-Zweig wird weiter gepflegt.

– Z.B.: nach Fehlerbeseitigung /tags/1.0.1


Arbeiten mit Releases

• Welche Konfigurationselemente haben wir?

– D.h. Dateien welcher Typen müssen versionsverwaltet werden?

• Nach welchen Strategien werden die Versionen verwaltet?

– Nach welchen Änderungen muss eingecheckt werden?

– Wann darf eingecheckt werden?

• Wer hat welche Rollen und Verantwortlichkeiten?

– Welche Personen sind für welche Komponenten zuständig?

• Welche Werkzeuge sollen benutzt werden?

– Häufig können nicht alle Dateitypen gleich gut verwaltet werden.

• Wo liegt das (Haupt-) Repository?


Versionsmanagement-Aktivitäten

Kleines Projekt

– Kleines Team

– Ein zentrales

Repository

– Jedes Team-Mitglied

darf alle Dateien lesen

und schreiben.

– Bekanntes Modell


Versionierung in verschiedenen

Entwicklungsprozessen (1)

[Kamann]

• Der Integration Manager liest Änderungen und integriert sie in

die Hauptversion.

• Er hat Schreibzugriff auf das Haupt-Repository.

• Alle anderen Entwickler haben Lesezugriff.




Mittelgroßes Projekt

• Jedes Entwicklerteam hat

ein eigenes Repository.

– Die eigenen Entwickler

haben Schreibzugriff.

– Alle anderen Entwickler

haben Lesezugriff.

[Kamann]

Sehr großes Projekt

– Hunderte von

Entwicklern

– Hierarchische

Versionierung

– Leutnant: Integration

Manager für einen Teil

des Projekts

– Diktator: Integration

Manager für alle Teile

des Projekts

• Er hat Schreibzugriff auf

das Haupt-Repository.




[Kamann]

• Wesentliche Features der Versionsverwaltung:

– Softwareentwicklungs-Artefakte sind ständigen Änderungen

unterworfen, die versioniert werden sollen.

– Unterstützung für nebenläufiges Arbeiten im Team.

– Konsistente Konfigurationen durch die Versionierung von Ordnern

und Dateien

– Häufiges Commit mit Dokumentation der Änderungen

– Verteilte Repositories für verteilte Versionskontrolle im Projekt

• Fortschritt in der Werkzeugentwicklung für Versionsverwaltung:

– CVS SVN Git

• Das Arbeiten mit Zweigen ist einfach und „billig“.

– Es macht das Arbeiten mit mehreren Releases einfacher.

– Es erlaubt eine entspannte und sichere Durchführung von

Evolutionsschritten.


Zusammenfassung

Sekundär-Literatur


• S. M. Easterbrook, E. E. Beck, J. S. Goodlet, L. Plowman, M. Sharplesand C. C. Wood: A Survey of Empirical Studies of Conflict, Easterbrook, S. M. (ed), 1993 CSCW: Cooperation or Conflict?, Springer-Verlag, pp. 1-68

• Ben Collins-Sussman, Brian W. Fitzpatrick, C. Michael Pilato: Version Control with Subversion, 2011, online erhältlich unter http://svnbook.red-bean.com/

• Apache Subversion: http://subversion.apache.org/

• Subversive: http://www.eclipse.org/subversive/

• Subclipse: http://subclipse.tigris.org/

• Scott Chacon, Ben Straub: ProGit, 2nd Edition, 2014, online erhältlich unter http://git-scm.com/book

• GitHub: http://github.com/

• Bitbucket: http://bitbucket.org/

• Atlassian SourceTree: http://sourcetreeapp.com/

• EGit: http://www.eclipse.org/egit/

• Thorsten Kamann: GIT oder Subversion? Sei kein Depp!, Eclipse Magazin, Ausgabe 1-2011

http://svnbook.red-bean.com/

http://subversion.apache.org/

http://www.eclipse.org/subversive/

http://subclipse.tigris.org/

http://git-scm.com/book

http://github.com/

http://bitbucket.org/

http://sourcetreeapp.com/

http://www.eclipse.org/egit/

Documents

Versionsverwaltung von Softwareartefakten - uni-marburg.de · –Diese Situation wird Konflikt genannt. •Lassen sich zwei Dokumente immer mischen? –Die Unterschiede zwischen zwei