Software Engineering 2 Versionsverwaltung

Transkript

1 Software Engineering 2 Versionsverwaltung Prof. Dr. Axel Böttcher 7. Oktober 2012

2 Lernziele Die Grundlegenden Konzepte kennen Mit einem Versionsverwaltungssystem produktiv arbeiten können Ein geeignetes Versionierungswerkzeug für ein Projekt auswählen können

3 Ausgangssituation Collective Ownership of the code Mehrere Programmierende arbeiten an einem Projekt. Fragen: Wie werden die Einzelteile zu einem Ganzen zusammengefügt? Wie bleibe ich auf dem Stand mit dem, was mein Kollege entwickelt? Was wurde seit dem letzten Realease/vorgestern/vom Kollegen geändert? Wer hat an meinem Code rumgewurstelt? Wie können unterschiedliche Releases gepflegt werden? Wie kann ich experimentieren und das Ergebnis entweder verwerfen oder zur Verfügung stellen? = Version Control Systems (VCS)

4 Repository Alle Änderungen werden in ein Repository geschrieben: commit bzw. push Komplette Änderungshistorie wird gespeichert! Gearbeitet wird in einer Sandbox Commits sind atomar, d.h. sie haben Transaktions-Charakter (entweder alle Änderungen oder keine werden übernommen) Häufige commits sind sehr wichtig!

5 Zentrales versus verteiltes Source Code Management zentral verteilt Repository genau eines beliebig viele Flaschenhals zentraler Server keiner Verteilte Entwickler Serverzugriff u.u. schneller Zugriff, langsam weil lokal Serverausfall Katastrophe Lokale Kopie(n) immer vorhanden Netzwerkverbindung immer erforderlich Nicht permanent erforderlich Versionsnummern eindeutig? Beispiele: SVN git, mercurial

6 Was kommt ins Repository Ignore Lists IMMER: nicht-generierter Source Code Konfigurationsdateien (einschl. Skripte für Hooks) Build-Skripte NIE: alles was sich aus dem versionierten Material generieren lässt, also Bytecode (.class-files,.jar-libraries etc.) generierter Code Executables Nutzen Sie ignore-listen, um bestimmte Teilbäume oder Dateitypen zu ignorieren

7 Status Unterschiede zwischen Working Copy und Repository 1. Beispiele: Nicht unter Versionskontrolle UND nicht auf der ignore-liste Hinzugefügt, aber noch nicht im Repo Modified, nicht committed umbenannt, verschoben, gelöscht aber noch nicht committed ohne Hilfe des VCS umbenannt, verschoben oder gelöscht andere Art von Objekt, als versioniert (z.b. Datei Dir) ausstehende Merges 1 bei git zwischen index und Head Commit; aber das ist im Moment kein wesentlicher Unterschied.

8 Basic workflows Checkout/import Checkout/import do some work Checkout/import do some work update do some work update merge commit commit commit

9 Was ist hier passiert?

10 Checkout/Commit Entwickler 1 checkout class SomeClass { void m1() { void m2() { commit Repo class SomeClass { void m1() { class SomeClass { void m1() { void m2() {

11 Not up-to-date Entwickler 1 Entwicklerin 2 Repo checkout class SomeClass { void m1() { void m2() { commit checkout class SomeClass { void m1() { void m3() { commit class SomeClass { void m1() { class SomeClass { void m1() { void m2() {

12 Merging Entwickler 1 Entwicklerin 2 Repo checkout class SomeClass { void m1() { void m2() { commit checkout class SomeClass { void m1() { void m3() { commit class SomeClass { void m1() { class SomeClass { void m1() { void m2() { class SomeClass { void m1() { void m2() { void m3() { update

13 Merging Bla.java 1 /** 2 * 3 axel 4 * 5 */ 6 public final class Bla { 7 8 /** 9 * magic number. 10 */ 11 <<<<<<<.mine 12 public static final int MAGICNUMBER = 789; 13 ======= 14 public static final int MAGICNUMBER = 123; 15 >>>>>>>.r /** 18 * laber fasel. 19 */ 20 private Bla() { 21

14 Merging So weit möglich wird Merging automatisch und kommentarlos vom Versionsverwaltungssystem durchgeführt. Merging kann aber auch schnell kompliziert werden: Inkompatible Änderungen an der selben Datei A und B benennen eine Datei um, aber mit unterschiedlichen neuen Namen A löscht eine Datei, B hat Änderungen daran vorgenommen A löscht eine Datei, B benennt sie Datei um Änderungen am Dateisystem nur mit VCS vornehmen! (git mv) etc.

15 File Merging Alternativen: mine full theirs full harte Arbeit Es gibt einen riesigen Zoo an Merge Tools. Viele Editoren bieten das mit an: Eclipse, vim,. Araxis

16 Branching Ein Branch (engl. für Ast, Zweig) ermöglicht es, von einem Ausgangspunkt aus mehrere Versionen der Software zu pflegen. Dafür kann es mehrere Gründe geben: Experiemnte, ohne die praduktive Entwicklung zu gefährden Bug-Fixes für ein ausgeliefertes Release vs. Weiterentwicklung für zukünftiges Release Zusammenführen von Branches ist möglich. Ebenso oftmals Cherry-picking. Der Wechsel zwischen Branches ist üblicherweise nur erlaubt, wenn keine un-committed changes vorliegen.

17 Hooks Hooks ermöglichen es, in den Prozess der Verwaltung von Daten im Repository einzugreifen. Typische Anwendungsfälle: Pre Commit Ausführung vor dem Commit. Der Commit kann abgebrochen werden, falls der Code im Hook entscheidet, dass er unzulässig ist: Kein Commit-Kommentar, oder Kommentar zu kurz Kein Bezug zu einem Issue aus dem eingesetzten Issue-Tracker Code-Formatierung entspricht nicht den Vorgaben Post Commit Ausführung nach erfolgreichem Commit. -Benachrichtigung an Mitglieder des Teams

18 Git Details Alle gespeicherten Objekte werden über 160-Bit SHA1-Hashes identifiziert. Der default Branch heißt master (bei svn: trunk)

19 Git-Datenstrukturen Blob Datei-Inhalt, keine Metainformationen, kein Dateiname Tree speichert Pfadnamen, Dateinamen, Referenzen auf Trees und Blobs Commit Metadaten über Änderungen (Autor, Kommentar etc.), Referenz auf Tree-Objekt, das den Commit repräsentiert, Referenzen auf Parent-Commits Tag Lesbare Namen für Commits (und andere Objekte)

20 Beispiel Commit mit 2 Dateien: SomeClass.java und log4j.properties: V1.0 Autor: ab@cs.hm.edu comment: initial import SomeClass.java log4j.properties class SomeClass { void m1() { void m2() { ### direct log messages to stdout ### log4j.rootcategory=info, stdout log4j.appender.stdout=org.apache.log4j.consoleappen der log4j.appender.stdout.target=system.out log4j.appender.stdout.layout=org.apache.log4j.patte rnlayout log4j.appender.stdout.layout.conversionpattern= %d{absolute %5p %c{1:%l - %m%n 9685ab135be01cba06db7fde0fdcb2499ef11cd4

21 Beispiel Commit nach Änderung an log4j.properties: V1.0 Autor: comment: initial import parent Autor: comment: log4j adapted SomeClass.java log4j.properties SomeClass.java log4j.properties class SomeClass { void m1() { void m2() { ### direct log messages to stdout ### log4j.rootcategory=info, stdout log4j.appender.stdout=org.apache.log4j.consoleappende r log4j.appender.stdout.target=system.out log4j.appender.stdout.layout=org.apache.log4j.pattern Layout log4j.appender.stdout.layout.conversionpattern= %d{absolute %5p %c{1:%l - %m%n 9685ab135be01cba06db7fde0fdcb2499ef11cd4 ### direct log messages to stdout ### log4j.rootcategory=warn, stdout log4j.appender.stdout=org.apache.log4j. ConsoleAppender log4j.appender.stdout.target=system.out log4j.appender.stdout.layout=org.apache.log4j.patternlayout log4j.appender.stdout.layout.conversion Pattern=%d{ABSOLUTE %5p %c{1:%l - %m %n

22 Übungsaufgabe Wie sieht die Datenstruktur aus, wenn nach dem ersten Commit 1. eine zusätzliche Datei Foo.java in das bestehende Verzeichnis eingefügt wird? 2. ein neues Verzeichnis angelegt und dort die Datei Foo.java erstellt wird?

23 Branching git unterstützt beliebig komplexes Branching. J K L stable E F G dev C D U V W A B X Y Z master P Q R S test Wechseln mit git checkout <branchname> Best practice: aktueller Entwicklungsbranch heißt master.

24 Arbeiten mit einem Remote Repository Commit: wirkt lokal Neue Konzepte: clone, pull und push Das Konzept der Versionsnummern zentraler VCSe wird problematisch.

25 Clone Mittels git vlone <git-url> wird ein Repository geklont, der Mater-branch als current branch ausgecheckt.

26 Cloning Original-Repository wnthält 3 Commits (A, B und C): A B C master Entwickler 1: nach Commit C geklont und ein weiterer lokaler Commit X: origin/master A B C X master

27 Cloning (Fortsetzung) Entwicklerin 2: ebenfalls nach Commit C geklont, zwei weitere lokale Commits erstellt (D und E) und gepusht (so genannter fast forward). Damit Zustand Original-Repository: A B C D E master Zustand lokales Repository von Entwickler 1 unverändert: origin/master A B C X master Beim Push entsteht das sog. non-fast-forward push problem.

28 Cloning (Fortsetzung) Ähnlich wie bei zentraler Versionsverwaltung muss Entwickler A einen pull oder fetch (update) durchführen, Mergen (was einen Commit erzeugt) und pushen. Zustand Original-Repository danach: D E A B C M master X

29 Übungsaufgabe Erweitern sie den dritten der Basic Workflows für die Situation mit einem zentralen git-repository.