1 WS 2012 Software-Engineering II Versionsverwaltung.

Präsentation zum Thema: "1 WS 2012 Software-Engineering II Versionsverwaltung."—  Präsentation transkript:

1 1 TIT10AIK @ WS 2012 Software-Engineering II Versionsverwaltung

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

3 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 4 TIT10AIK @ WS 2012 Distributed vs. Centralized Version Control System Distributed Revision Control Centralized Revision Control GIT Concurrent Versions System (CVS) Subversion (SVN) Vorlesungsinhalt Centralized: Es gibt einen Server, der den Quellcode zentral verwaltet. Distributed: Jeder Entwickler hat eine lokale Instanz der Server-Software, die sich mit anderen Server-Instanzen synchronisieren kann.

5 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 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 7 TIT10AIK @ WS 2012 Centralized Optimistic Revision Control Repository Working Copy des Entwicklers Working Copy des Entwicklers Working Copy des Entwicklers

8 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 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 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 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 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 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 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 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 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 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 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 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 20 TIT10AIK @ WS 2012 Practical Guidelines »3 verschiedene Arten von Branches »Trunk »Feature Branches »Release Branches

21 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 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 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 24 TIT10AIK @ WS 2012 Release-Branch erstellen $ svn copy http://[url]/trunk http://[url]/branches/DATE-NAME Der Branch wird vom Trunk erstellt Für Branch-Namen sollte ein Schema gefunden werden branches/2009-01-01-New-Years-Features

25 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 26 TIT10AIK @ WS 2012 Release-Branch updaten »Bei kleinen Bugfixen kann der Release- Branch aktualisiert werden »$ cd »$ 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 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 sind 2.Nicht möglich sind

28 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 29 TIT10AIK @ WS 2012 Feature Branch erstellen $ svn copy http://[url]/trunk http://[url]/branches/dev-XXX Der Branch wird vom Trunk erstellt Für Branch-Namen sollte ein Schema gefunden werden branches/dev(elopment)-Branchname

30 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 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 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 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 –mMerged back branch to trunk »Ab diesem Moment ist die Entwicklung in diesem Branch abgeschlossen trunk feature branch

34 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 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 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