Versionsverwaltung von Softwareartefakten - uni-marburg.de · Taentzer Einführung in die Softwaretechnik 45 Das Problem Zwei Nutzer entscheiden sich, an demselben Dokument zu arbeiten

Versionsverwaltung von Softwareartefakten

21. Oktober 2014

Taentzer Einführung in die Softwaretechnik 43

Überblick

Wie verwaltet man Softwareartefakte? Versionskontrolle für verschiedene Softwareartefakte:

Anforderungsdokumente, Modelle, Code, Testdateien, Dokumentationen, etc.

Möglichst unabhängiges Arbeiten im Team Nutzen: Dokumentation von Änderungen, Konflikte erkennen und

lösen, Release zusammenstellen

Einführung in Versionsverwaltungswerkzeuge SVN – zentrale Verwaltung von Dateien und Ordnern Git – Verteilte Versionsverwaltung


Versionsverwaltung

Ein Versionsverwaltungssystem soll das gemein-schaftliche 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.


Das Problem Zwei Nutzer entscheiden

sich, an demselben Dokument zu arbeiten.

Beide führen verschiedene Änderungen an ihren lokalen Versionen des Dokuments durch.

Die lokalen Versionen werden nacheinander in das Repository geschrieben.

Der zweite Nutzer überschreibt dadurch eventuell Änderungen des ersten Nutzers.

aus „Version Control with Subversion“


Problemlösung durch Sperren von Dokumenten

Der erste Nutzer sperrt das Dokument und arbeitet lokal daran.

Der zweite Nutzer möchte das Dokument lesen, es ist aber gesperrt.

Der erste Nutzer schreibt sein geändertes Dokument ins Repository und entsperrt es.

Der zweite Nutzer kann nun das Dokument lesen und für andere sperren.



Wie gut ist diese Problemlösung?

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.


Problemlösung durch Mischen von Dokumenten

Die Nutzer kopieren das Dokument in ihre lokalen Ordner.

Sie arbeiten unabhängig daran. Einer schreibt als Erster das

Dokument in das Repository zurück.

Der Zweite kann das Dokument nicht zurückschrieben: „out of date“



Problemlösung durch Mischen von Dokumenten

Der Zweite vergleicht seine lokale Version mit der aktuellen im Repository.

Beide Versionen werden gemischt.

Die neue (gemischte) Version wird zurückgeschrieben.

Die neue Version kann ausgelesen werden.



Eigenschaften dieser Problemlösung

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.

Die Praxis hat gezeigt, dass die meisten nebenläufigen Änderungen an einem Dokument konfliktfrei sind.


Revisionen

Revision: Ein Zustand der zu verwaltenden Softwareartefakte

Softwareartefakte sind in Ordnern gegliedert.

Versionsverwaltung sollte nicht nur die Dateien, sondern auch die Ordner verwalten.


Subversion

Versionsverwaltungssoftware für Dateien UND Ordner Open Source Software von CollabNet entwickelt:

http://subversion.apache.org/ Features:

Versionierung von Ordnern und Dateien Auch das Umbenennen, Erzeugen und Löschen von Ordnern

werden festgehalten. Sammlung von Änderungen wird als Transaktion verwaltet.

SVN-Book unter: http://svnbook.red-bean.com/ Subclipse: Subversion für Eclipse:

http://subclipse.tigris.org/


Neues Repository aufsetzen

Repository erzeugen: svnadmin create <Repositoryname>

Initial Repositorystruktur aufsetzen: svn import <Name> file://<Ordnername>

Repository anzeigen: svn list file://<Repositoryname>


Typischer Arbeitszyklus

Arbeitskopie auf den neuesten Stand bringen: svn update

Änderungen an der Ordner-struktur durchführen: svn add svn delete svn copy svn move

Änderungen prüfen: svn status svn diff

Änderungen zurücknehmen (optional): svn revert

Konflikte auflösen: svn update svn resolved

Änderungen in das Repository einlesen: svn commit


Subversion in Eclipse Eclipse Plugins: Subversive,

Subclipse Wechsel zur SVN Repository

Exploring Perspective Für das Arbeiten mit einem

bestehenden Repository muss die Repository Locationangegeben werden: New Repository Location

Neues Repository anlegen:New Repository

Für den Import eines bestehenden Projekts in das SVN Repository: Import eclipse.org/subversive


Subversion in Eclipse

In SVN Repository Explorer: Checkout lädt eine bestimmte Revision aus dem Repository herunter.

Lokales Arbeiten in der Java-Perspektive. SVN-Befehle unter Team →…

Synchronisation im Team: Überblick über Änderungen im Projekt: Window→OpenPerspective → Other..., dort Team Synchronizing Die Team Synchronization

Perspective wird gestartet.subclipse.tigris.org


Git Software für verteilte Versionsverwaltung Kein zentraler Server nötig Lokale Kopie des gesamten Repository

Lokale Funktionalität ähnlich wie bei SVN Neue Features:

Versionen als Schnappschüsse eines Mini-Dateisystems Nichtlineare Entwicklung von Software: einfaches Branching und

Merging Datenabgleich zwischen verschiedenen Repositories möglich

Git-Buch: ProGit unter: http://git-scm.com/book Git in Eclipse: http://www.eclipse.org/egit

Aufbau eines zentralen Repository ein zentrales Repository für

die Arbeitsgruppe z.B. in der Cloud

lokale Arbeitsbereiche oderlokale Repositories


confluence.atlassian.com


Git in Eclipse 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 →…

eclipse.org/subversive

Clone eines Git Repository Um lokal auf das

entfernte Repository zugreifen zu können Auswahl einzelner

Branches Angabe des lokalen

Ordners


Lade lokaleSourcen

Push lädt einen lokalen Branchoder eine Reihe von Commits in ein entferntes Repository.

zum Veröffentlichen von Beiträgen

Pull lädt einen Branch runter.


Entferntes Repository


Austausch zwischen Repositories: Ein Beispielablauf

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


aus „ProGit“

Vergleich verschiedener Versionen


Versionierung in verschiedenen Entwicklungsprozessen

Kleines Projekt: Kleines Team Ein zentrales Repository Jedes Team-Mitglied darf

alle Dateien lesen und schreiben.

Bekanntes Modell


aus „ProGit“

Versionen als Schnappschüsse

Version: Mini-Dateisystem in einem Zustand Unveränderte Dateien werden nicht kopiert.

Git fügt nur Daten hinzu.


aus „ProGit“

Typische Git-Befehle auf lokalem 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>


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

aus „ProGit“

Der Default-Branch heisst „master“.

Zwei Branches können auf denselben Schnappschuss verweisen.

Der aktuelle Branch heisst „HEAD“.


Branches

aus „ProGit“

Branches

Die Historie läuft auseinander:Beispiel: „master“-Branch „testing“-Branch

Der Nutzer kann… beliebig zwischen den

Branches wechseln. die Branches zusammen-

führen


aus „ProGit“

Beispiel für Branches


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


Mittelgroßes Projekt: Jeder Entwickler hat ein eigenes Repository.

Der eigene Entwickler hat Schreibzugriff. Alle anderen Entwickler haben Lesezugriff.

Der Integration Manager liest Änderungen und integriert sie in die Hauptversion. Er hat Schreibzugriff auf das Haupt-Repository. Alle anderen Entwickler haben Lesezugriff.


aus „ProGit“


Sehr großes Projekt: Hunderte von Entwicklern Hierarchische Versionierung Lieutenant: Integration

Manager für einen Teil des Projekts

Dictator: Integration Manager für alle Teile des Projekts Er hat Schreibzugriff auf das

Haupt-Repository.


aus „ProGit“


Zusammenfassung Wesentliche Features der Versionsverwaltung:

Anforderungsdokumente, Modelle, Code, Testdateien, Dokumentationen, etc. 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 Verschiedene Branches für verschiedene Entwicklungen im Projekt Verteilte Repositories für verteilte Versionskontrolle im Projekt

Fortschritt in der Werkzeugentwicklung f. Versionsverwaltung: CVS SVN Git

Documents

Versionsverwaltung von Softwareartefakten - uni-marburg.de · Taentzer Einführung in die Softwaretechnik 45 Das Problem Zwei Nutzer entscheiden sich, an demselben Dokument zu arbeiten