Versionsmanagement. Software(technik)praktikum: Vorlesung 2: Versionsmanagement

Transkript

1 1 Versionsmanagement

2 2 Versionsmanagement Motivation Ausgangslage Softwareentwicklung ist Teamarbeit Viel (indirekte) Kommunikation nötig Entwicklungswissen muss dokumentiert wissen Software besteht aus vielen Dokumenten Lastenheft Pflichtenheft Analyse- und Designdokument Programmcode Dokumentation Handbuch

3 3 Versionsmanagement Motivation Konsequenz Verschiedene Personen greifen (gleichzeitig) auf Dokumente Oft bearbeiten verschiedene Personen gleichzeitig (unabhängig voneinander) dasselbe Dokument

4 4 Versionsmanagement Motivation Typische Probleme / Fragen Versionsmanagement Wo ist die aktuelle Version? Was ist die zuletzt lauffähige Version? Wo ist Implementierungsversion vom 01. April 2012? Und welche Dokumente beziehen sich auf diese Version? Welche Version wurde dem Kunden Schäfer präsentiert? Änderungsmanagement Was hat sich seit letzter Woche geändert? Wer hat diese Änderung gemacht? Warum wurde diese Änderung gemacht?

5 5 Versionsmanagement Motivation Einfache Lösungen Austausch der Dokumente via USB- Stick / Festplatte Austausch der Dokumente via Mail Netzwerkfestplatte Konventionen und Regeln werden im Team definiert

6 6 Versionsmanagement Motivation Einfache Lösungen erzeugen neue Problem Konventionen und Regeln werden nicht eingehalten Koordination ist aufwendig und führt zu Verzögerungen Varianten und Konfigurationen werden von Hand verwaltet Versions- und Änderungsfragen nicht bzw. nur schwer beantwortbar Geistige Kapazität wird mit Kleinkram verschwendet Fazit: Konventionen müssen technisch erzwungen werden!

7 7 Versionsmanagement Motivation Sinnvolle Lösung Versions- und Konfigurationsmanagementsysteme Lösen (bei vernünftiger Anwendung) alle genannten Probleme (fast) ohne Zusatzaufwand Bieten sogar Zusatzleistungen (z.b. einfache Datensicherung)

8 8 Versionsmanagement Konzepte Repository Dokumente in hierarchischer Struktur Versionsverwaltungssystem Koordination der Zugriffe und Modifikationen, insbes. Wahrung der Konsistenz Nutzer Nutzer Zugriff und Modifikation von Dokumenten

9 9 Konsistenzmechanismen Optimistische Mechanismen System erlaubt gleichzeitiges Bearbeiten des Dokuments durch verschiedenen Personen System erkennt und integriert die Änderungen (Merging) Evtl. funktioniert das nicht automatisch; dann muss der Konflikt manuell beseitigt werden Pessimistische Mechanismen System verbietet gleichzeitiges Bearbeiten des Dokuments durch verschiedenen Personen (Sperrprotokolle) Beide Mechanismen haben Vor- und Nachteile (hierzu später mehr)

10 1 Optimistischer Ansatz Repository Versionsverwaltungssystem Lokale Kopien des Repositories (Arbeitsverzeichnis) Nutzer Nutzer

11 1 Pessimistischer Ansatz Ablauf zur Bearbeitung einer Datei file.txt: checkout file.txt < Bearbeitung der Datei > checkin file.txt Zwischen checkout und checkin kann kein anderer Nutzer die Datei verändern. Genaue Syntax und Optionen der Kommandos hängen vom Versionsverwaltungssystem ab.

12 1 Optimistischer Ansatz update - Nutzer aktualisiert seine lokale Kopie des Repositories commit - Nutzer übergibt seine lokale Kopie an das Repository (Versionsnummer wird inkrementiert) Ändern der lokalen Kopie durch Nutzer jederzeit erlaubt (es gibt keine Sperren) update und commit sind (nahezu) jederzeit erlaubt Genaue Syntax und Optionen der Kommandos hängen vom Versionsverwaltungssystem ab.

13 1 Optimistischer Ansatz Mischen (Merge): Szenario 1 file.txt file.txt Änderungen im Repository (durch commit anderer Benutzer) Änderungen im Arbeitsverzeichnis

14 Optimistischer Ansatz Mischen (Merge): Szenario 1 file.txt file.txt update (+ ggf. merge) Änderungen im Repository Merge: Änderungen aus dem Repository (seit der letzten Aktualisierung) und der Änderungen im lokalen Verzeichnis Aktualisierte Version im Arbeitsverzeichnis 14 1

15 1 Optimistischer Ansatz Mischen (Merge): Szenario 1 file.txt Bei gängigen Systemen funktioniert das erstmal nur mit Text-Dateien (z.b..java oder.tex) file.txt update Änderungen im Repository Aktualisierte Version im Arbeitsverzeichnis

16 1 Optimistischer Ansatz Mischen (Merge): Szenario 2 file.txt file.txt Änderungen im Repository Änderungen im Arbeitsverzeichnis

17 1 Optimistischer Ansatz Mischen (Merge): Szenario 2 file.txt Konflikt file.txt update Änderungen im Repository Änderungen im Arbeitsverzeichnis

18 1 Optimistischer Ansatz Konflikte Konflikte werden in der Datei im Arbeitsverzeichnis markiert: <<<<<< Änderung Änderung 2 >>>>>> Konflikte müssen vom Benutzer in seiner Arbeitskopie von Hand korrigiert werden. Hinweis: Konflikte entstehen nur Arbeitsverzeichnis

19 1 Optimistischer Ansatz Mergen binärer Dateien Für Textdateien existieren gute Merge-Algorithmen Java, Latex,... somit gut vergleichbar und mergebar Für binäre Dateien müssen separate Merge-Algorithmen vorhanden sein Beispiel: MS Word-Dokument Word bietet jedoch intern Vergleichs- und Mergeoptionen Hinweis: In Versionsverwaltungssystemen kann man angeben, ob eine Datei binär ist

20 2 Optimistischer Ansatz Frage bzgl. Commit Frage: Was passiert, wenn der Nutzer ein commit durchführt, und dabei Änderungen im Repository noch nicht in sein Arbeitsverzeichnis übernommen hat? Antwort: Wird durch Repository-Client verboten. Client fordert, dass erst update ausgeführt wird Commit erst danach möglich Commit nur möglich, wenn lokales Repository konfliktfrei ist

21 2 Optimistischer Ansatz Commit-Unterbindung v100 v100 Versionsverwaltungssystem v100

22 2 Optimistischer Ansatz Commit-Unterbindung v100 Versionsverwaltungssystem v100* v100* v100

23 2 Optimistischer Ansatz Commit-Unterbindung > commit up-to-date check failed v101 > commit Versionsverwaltungssystem v100* v101

24 2 Optimistischer Ansatz Commit-Unterbindung > commit up-to-date check failed > update M file.txt v101 Versionsverwaltungssystem v100* v101* v101 > commit

25 2 Optimistischer Ansatz Commit-Unterbindung > commit up-to-date check failed > update M file.txt > commit v101* v102 v101 v102 Versionsverwaltungssystem > commit v101

26 Unterstützung für Versionsmanagement in Eclipse 26 2

27 2 Vergleich: Pessimistisch vs Optimistisch Pessimistische Mechanismen ++ keine Konflikte -- kein gleichzeitiges Arbeiten an demselben Dokument (bei großen Dateien behindert es die Teamarbeit) -- Dateien können unabsichtlich lange gesperrt sein Optimistische Mechanismen -- Konflikte (oft vermeidbar bei sehr guter Absprache) ++ gleichzeitiges Arbeiten an Dokumenten möglich Für typische Softwareprojekte (große und verteilt arbeitende Teams) haben sich die optimistischen Mechanismen als zweckmäßiger erwiesen

28 2 Versionierungsart Repository-Versionierung Repository-Versionierung Je commit gibt es eine neue Repository-Nummer Head ist neueste Repository-Version >>commit <<changed>> <<added>> V4 Main.java Appl.java <<added>> >>commit V3 <<added>> main.html >>commit V2 <<added>> index.html >>commit V1 Main.java

29 2 Versionierungsart Dateiversionierung Dateiversionierung Jede Datei hat ihre eigene Version Je Commit werden Versionsnummern der Dateien inkrementiert Konfiguration: Menge von Dateiversionen Konfiguration: Heute (head) Release V1.2 V1.2 V1.1 V2.0 V1.1 V1.1 V1 V1 V1 V1 Main.java Appl.java index.html main.html

30 3 Weitere Features von Versionsmanagementsystemen Zugriff auf alte Versionen Alte Versionen sind jederzeit zugreifbar (wichtiger Unterschied zu simpler Netzwerkfestplatte) Versionsvergleich Differenz der Dateien markiert Änderungen Branching Alternative Entwicklungszweige ermöglichen das Versionieren von Varianten (z.b. Implementierung eines alternativen Benutzerinterfaces) Tagging Versionen markieren (z.b. Release 1.0)

31 3 Weitere Features von Versionsmanagementsystemen Kommitkommentar Mit jedem commit kann (und sollte) man in einem kurzen Kommentar angeben, welche Änderungen vorgenommen wurden Mailbenachrichtung Bei Änderungen von Dateien können automatisch Nachrichten an andere Nutzer verschickt werden Blame-Analyse Man kann für jede Datei feststellen, welche Zeile von welchem Nutzer zuletzt bearbeitet wurde (blame) Verknüpfung mit Ticketmanagementsystem Tickets (z.b. Trac) für Bug-Reports und Features-Requests können sich auf Versionsnummern beziehen

32 3 Inhalt für das Repository Welche Dokumente und Dateien gehören ins Repository? Alle Dokumente und Dateien, die zur Software und ihrem Entwicklungsprozess gehören und nicht automatisch aus den anderen Dateien oder Dokumenten generiert werden können z.b. Keine temporären Latex-Dateien *.aux, *.bbl,... vermeiden, trotzdem Kopien anzulegen! (Kopie (1) von, Kopie (2) von, Kopie (3) von )

33 3 Praktikum: SVN Im Praktikum nutzen wir optimistische Mechanismen Konkret: Subversion (SVN) Wird eingesetzt bei Apache, SourceForge, Google Code,... Features: Commit-Kommentare Mailbenachrichtung bei jedem Checkin Blame-Analyse Verknüpfbar mit Ticketmanagementsystem (z.b. Trac) Viele SVN-Clients, u.a. Subclipse und Subversive für Eclipse TortoiseSVN Integriert sich in Windows-Explorer

34 3 Praktikum: SVN SVN unterstützt nur Repository-Versionierung SVN unterscheidet zwischen trunk (Stamm): Standardentwicklungspfad tags (Markierung): Meilensteine, Abgaben, Release,... branch (Verzweigung): temporäre Pfade für Varianten Zeit

35 3 Zusammenfassung Versionsmanagementsysteme erleichtern das gemeinsame Arbeiten an Dokumenten und Dateien Änderungen sind nachverfolgbar Alte Versionen sind zugreifbar Im Praktikum nutzen wir das optimistische Verfahren SVN Üben Sie das Arbeiten mit SVN Nutzen Sie unser Tutorial auf der Webseite. Nutzen Sie die Tutorials im Web