1 TIT10AIK @ WS 2012 Software-Engineering II Versionsverwaltung.

1 TIT10AIK @ WS 2012

Software-Engineering II

Versionsverwaltung


Themenübersicht» Objektorientierung» Aspektorientierung» Vorgehensmodelle» UML» Analyse- & Entwurfsmuster» Objektorientiertes Testen» Versionsverwaltung» Refactoring» Labor (Praktischer Teil)


Versionskontrolle

» Bei der Software-Entwicklung im Team greifen unterschiedliche Teilnehmer auf gemeinsame Ressourcen schreibend und lesend zu

» Strategie erforderlich» Synchronisation der Zugriffe» Vermeiden eines Verlustes von Änderungen

» Versions-Historie von Dateien sehr hilfreich in vielen Fällen


Distributed vs. Centralized

Version Control System

Distributed Revision Control

Centralized Revision Control

GITConcurrent

Versions System(CVS)

Subversion

(SVN)

Vorlesungsinhalt

Centralized:

Es gibt einen Server,der den Quellcode zentralverwaltet.

Distributed:

Jeder Entwickler hateine lokaleInstanz derServer-Software,die sich mit anderen Server-Instanzen synchronisieren kann.


Konflikt-Lösung bzw. -Vermeidung

» Pessimistic Revision Control» Nur eine Person darf zu einer Zeit eine Datei

bearbeiten» Pessimistischer Ansatz: Gleichzeitiges Bearbeiten ist

nicht ohne großen Merge-Aufwand möglich» Zyklus: Lock – Modify - Write

» Optimistic Revision Control» Beliebig viele Entwickler können Dateien gleichzeitig

editieren» Optimistischer Ansatz: In der Regel ist das Mergen

von Dateien ohne größere Probleme möglich» Zyklus: Copy – Modify – Merge» Jeder Entwickler besitzt eine lokale Kopie des

gesamten Repository


Vertreter

Version Control System

Pessimistic Revision Control

Optimistic Revision Control

Revision Control System

(RCS)

Concurrent Versions System

(CVS)

Subversion

(SVN)

Vorlesungsinhalt


Centralized Optimistic Revision Control

Repository

Working Copy des Entwicklers




Aktionen

» Check-Out» Holt eine bestimmte Version eines Repository initial aus dem System

» Update» Aktualisiert die lokale Version auf den neusten Stand

» Führt merging durch, falls lokal Anderungen an aktualisierten Dateien bestehen

» Commit» Checkt geänderte Dateien in das Repository ein

» Revert» Macht noch nicht eingecheckte Änderungen in der lokalen Working Copy rückgängig


Tags

» Durch das Setzen eines Tags kann ein aktueller Stand eines Repository markiert (getagged) werden

» Dadurch ist es später einfach, den mit einem Tag versehenen Stand wieder auszuchecken

10 TIT10AIK @ WS 2012

Branches

» Ein Branch ist ein Extra-Ast im Repository, welcher separat weiterentwickelt werden kann

Hauptzweig

t

1. Branch

2. Branch

3. Branch

Es ist möglich Branches wieder auf andere Branches oder den Hauptzweig zu mergen

11 TIT10AIK @ WS 2012

Branches

» Branches werden oft erstellt, wenn eine Software einen Release-Zustand erreicht hat

» Damit später auftretende Bugs in alten Versionen behoben werden können, ist es nötig, getrennte Codebasen zu haben

» Bugfixes können von „alten“ Branches in den Hauptzweig oder in andere Branches gemergt werden

12 TIT10AIK @ WS 2012

CVS

» 1989 entstanden» Speicherung

» Repository-Daten werden als gewöhnliche Dateien mit Zusatzinformationen auf dem Dateisystem gespeichert» Die Dateien auf dem Dateisystem sind wie im Repository organisiert

» Geschwindigkeitseinbußen» Jede Datei im Repository hat eine eigene Revisionsnummer

» Kaum weitere Meta-Informationen zu Dateien möglich» .cvsignore: Die hier aufgeführten Dateien werden in der Sandbox ignoriert

» Keine atomaren Commits » (E.g. Verbindungsabbrüche!!!)

13 TIT10AIK @ WS 2012

Tags, Branches, Hauptzweig

» Der „Hauptzweig“ wird bei CVS HEAD genannt

» Revisionsnummern sind nicht Repositoryweit

» Spezielle Version nur über ein genaues Datum definierbar

» Tags sind hier deshalb sehr wichtig» Eine spezielle Revision wird markiert

» Branching ist ein relativ aufwendiges Verfahren

14 TIT10AIK @ WS 2012

Subversion

Version Control with Subversion

(„svn-book“)

Online-E-Book

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

Ben Collins-Sussman

Brian W. Fitzpatrick

C. Michael Pilato

15 TIT10AIK @ WS 2012

Subversion

» Nachfolger von CVS» Open Source» Repository-Nummern beziehen sich auf das komplette Repository» Haben zwei Dateien die gleiche Revisionsnummer, wurden sie mit dem gleichen Commit eingecheckt

» Speicherung in einer FSFS-Datei-Struktur» Bessere Performance

» Atomare Commits. Entweder ganz oder gar nicht!

16 TIT10AIK @ WS 2012

Properties

» Dateien/Verzeichnisse können Properties besitzen

» Steuerung von Subversion » Ablegen von Meta-Informationen» Bsp.:

» svn:ignore bei Verzeichnissen definiert, welche Dateien in der Working Copy ignoriert werden sollen

» svn:externals gibt URLs von Repositories an, die in dieses Verzeichnis eingebunden werden sollen

17 TIT10AIK @ WS 2012

Tags, Branches, Hauptzweig

» Konventionen:» Der „Hauptzweig“ wird bei SVN Trunk genannt

» Da Revisionsnummern repositoryweit sind, kann eine spezielle Version bereits darüber spezifiziert werden

» Tags sind in SVN deshalb von deutlich weniger Bedeutung als bei CVS

» Branching geht sehr einfach» Es wird eine Kopie vom Trunk oder einem Branch erstellt

» $ svn copy http://[url]/trunk http://[url]/branches/new_branchname

18 TIT10AIK @ WS 2012

Korrekter Code!

» Nie fehlerhaften Quellcode einchecken» Egal ob im Trunk oder im eigenen Branch

» Der Code muss Compilierbar sein» Der Code sollte fehlerfrei sein

» Hooks erlauben das Kontrollieren von Commits

19 TIT10AIK @ WS 2012

Hooks

» Shell Skripte, liegen im SVN-Server-Verzeichnis» Pre-Commit

» Shell-Skript wird vor dem Committen ausgeführt» Erlaubt das Verweigern eines Commits» Bsp.: Syntaxcheck von Sourcecode, XML-Dateien

» Post-Commit:» Shell-Skript wird nach dem Committen ausgeführt» Keine Möglichkeit den Commit abzubrechen» Bsp.: Teammitglieder über Commits informieren,

Continuous-Integration-Server antriggern» …

20 TIT10AIK @ WS 2012

Practical Guidelines

» 3 verschiedene Arten von Branches

» Trunk» Feature Branches» Release Branches

21 TIT10AIK @ WS 2012

Trunk

» Der Trunk enthält nur „Stable“ Features» Stable bedeutet, dass zu jedem Zeitpunkt, bei jeder Revision» Der Code releast werden könnte» Vom Stand ein Development-Branch gemacht werden könnte

» Alle Commits in stable branches müssen atomar sein

» Es macht oft keinen Sinn direkt im Trunk zu entwickeln, denn» Man sollte so oft wie möglich committen» In der Regel sind viele commits nötig, bis eine stable Version vorliegt

22 TIT10AIK @ WS 2012

Trunk - Ausnahmen

» Direkt im Trunk entwickeln bei:» Bugfixes» Erweiterungen, die so klein sind, dass sie nur einen Commit benötigen

» Aber: » Oft werden Features unterschätzt, es fehlen am Ende Resourcen wie Übersetzungen oder Grafiken, die das Feature so lange blockieren

» So lange nicht alle Resource fertig sind, darf nicht committed werden

23 TIT10AIK @ WS 2012

Release Branches

» Ist eine Entwicklung abgeschlossen, wird ein neuer Release-Branch erzeugt

» Die Version dieses Branches wird deployed

trunk

release

release branch

release

24 TIT10AIK @ WS 2012

Release-Branch erstellen

$ svn copy http://[url]/trunk http://[url]/branches/DATE-NAME

Der Branch wird vomTrunk erstellt

Für Branch-Namen sollte einSchema gefunden werden

branches/2009-01-01-New-Years-Features

25 TIT10AIK @ WS 2012

Merging im Release Branch

» Nicht jede stabile Änderung im Trunk benötigt einen neuen Release Branch (Z.B.: Bugfixes)

» Entscheidend ist der Umfang der Änderungen

trunk

release

release branch

release

Bugfixes

26 TIT10AIK @ WS 2012

Release-Branch updaten

» Bei kleinen Bugfixen kann der Release-Branch aktualisiert werden

» $ cd <branch_checkout_dir>» $ svn up» $ svn merge –rXXX:YYY [REP.URL]/trunk» $ svn commit

» XXX:YYY ist der Bereich der zu mergenden Commits im Trunk (Bsp.: 100:104)

» XXX exklusive (wird nicht gemergt)

» Nur eine Revision mergen (REV-1):REV

27 TIT10AIK @ WS 2012

Hotfixes im Release Branch

» Entwickelungen direkt im Release Branch sollten generell vermieden werden

» Bugfixes zuerst im Trunk machen, dann in den Release Branch mergen

» Gefahr: Bugfixes werden nicht in den Trunk übernommen – beim nächsten Release-Branch fehlt der Bugfix

» Kein Software-Entwickler will einen Fehler zwei Mal beheben!

» Ausnahme: Änderungen, die für den Trunk 1. Nicht mehr nötig sind2. Nicht möglich sind

28 TIT10AIK @ WS 2012

Feature Branches

» Neuentwicklungen, umfangreicher als dass sie mit einem Commit im Trunk abgeschlossen werden können

trunk

feature branch 1

feature branch 2

29 TIT10AIK @ WS 2012

Feature Branch erstellen

$ svn copy http://[url]/trunk http://[url]/branches/dev-XXX

Der Branch wird vomTrunk erstellt

Für Branch-Namen sollte einSchema gefunden werden

branches/dev(elopment)-Branchname

30 TIT10AIK @ WS 2012

Was ist ein Feature?

» Beginnt ein Team mit mehreren Features zur selben Zeit kann es Sinn machen, nicht jedes Feature in einem separaten Branch zu entwickeln

» Extra Branch wenn» Features nicht korrespondieren und von gegenseitigen Entwicklungen nicht profitieren können

» Die geplanten Release-Dates der Features sehr unterschiedlich sind (Eine Lang-Zeit-Entwicklungs- und ein kurzes Feature)

31 TIT10AIK @ WS 2012

Branch aktuell halten

» Durch kontinuierliches Mergen mit dem Trunk sollte der Branch aktuell gehalten werden

» 1-2 Mal pro Woche» Ansonsten ist das Zurück-Mergen am Schluss sehr schwierig» Wenn mehrere Personen an dem Branch arbeiten, sollte eine Person als

dafür Zuständig erklärt werden» Das Zurück-Mergen ist in Version 1.4 relativ aufwändig: Bereits gemergte

Änderungen dürfen nicht noch einmal gemerged werden» In Version 1.5 wurde Merge-Tracking eingeführt: Dadurch muss nicht

darauf geachtet werden, ob ein Merge dieser Revision bereits gemacht wurde

trunk

feature branch 1

feature branch 2

32 TIT10AIK @ WS 2012

Merging-Syntax (1.4)

» Um mergen zu können, benötigt man die Revisionsnummer des letzen Merges

» Beim 1. Merge ist diese die Revisionsnummer bei der der Branch erstellt wurde. Diese Nummer steht in der letzten Zeile der Ausgabe von “svn log --stop-on-copy”

» Bei späteren merges kann man durch “svn log --stop-on-copy” die Revisionsnummer des letzten merges herausfinden

» Voraussetzung dafür ist, dass bei jedem Merge das selbe Schema für den Commit String verwendet wird

» $ svn merge [url]/svn/ncs/trunk -r XXXX:HEAD» $ svn commit -m"merged -r XXXX:HEAD from trunk"

33 TIT10AIK @ WS 2012

Feature abschließen

» Ist das Feature abgeschlossen, muss es wieder in den Trunk gemergt werden» In das Verzeichnis eines Trunk Checkouts wechseln» Trunk nochmals aktualisieren» Aktuelle Revisionsnummer des Trunks notieren (XXX)» $ svn merge .@XXXX [url]/branches/branchname@XXXX» $ svn commit –m“Merged back branch to trunk“

» Ab diesem Moment ist die Entwicklung in diesem Branch abgeschlossen

trunk

feature branch

34 TIT10AIK @ WS 2012

Server-Software

» Server-Software unter http://subversion.tigris.org/

» In vielen Linux-Distibutionen bereits im Paket-Installer enthalten» Debian: apt-get install subversion

» Für HTTP-Verbindung:» Apache Modul dav_svn

35 TIT10AIK @ WS 2012

Die wichtigsten Zugriffsarten

» Subversion bietet eine Vielzahl an Möglichkeiten, auf das Repository zuzugreifen

» http:// bzw. https://» Zugriff erfolgt durch eine HTTP-Verbindung

» (Ermöglicht auch mit HTTP-Proxy das auschecken)» Achtung: Bei HTTP keine Verschlüsselung der Authentifizierung

» svn+ssh:// » Software erzeugt eine SSH-Verbindung zum Server und Tunnelt dadurch die Kommunikation

36 TIT10AIK @ WS 2012

Tools

» Tortoise SVN» Windows Explorer Integration» http://tortoisesvn.tigris.org/

» Subversive» Eclipse Plugin» http://www.eclipse.org/subversive/

» Command Line Clients

1 TIT10AIK @ WS 2012 Software-Engineering II Versionsverwaltung.

Documents

Transcript of 1 TIT10AIK @ WS 2012 Software-Engineering II Versionsverwaltung.