Upload
sigmund-gersbach
View
110
Download
2
Embed Size (px)
Citation preview
1 TIT10AIK @ WS 2012
Software-Engineering II
Versionsverwaltung
2 TIT10AIK @ WS 2012
Themenübersicht» Objektorientierung» Aspektorientierung» Vorgehensmodelle» UML» Analyse- & Entwurfsmuster» Objektorientiertes Testen» Versionsverwaltung» Refactoring» Labor (Praktischer Teil)
3 TIT10AIK @ WS 2012
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
4 TIT10AIK @ WS 2012
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.
5 TIT10AIK @ WS 2012
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
6 TIT10AIK @ WS 2012
Vertreter
Version Control System
Pessimistic Revision Control
Optimistic Revision Control
Revision Control System
(RCS)
Concurrent Versions System
(CVS)
Subversion
(SVN)
Vorlesungsinhalt
7 TIT10AIK @ WS 2012
Centralized Optimistic Revision Control
Repository
Working Copy des Entwicklers
Working Copy des Entwicklers
Working Copy des Entwicklers
8 TIT10AIK @ WS 2012
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
9 TIT10AIK @ WS 2012
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