Versionsmanagement

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

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 Software(technik)praktikum: Vorlesung 2: Versionsmanagement

3. Versionsmanagement Motivation Konsequenz • Verschiedene Personen greifen (gleichzeitig) auf Dokumente • Oft bearbeiten verschiedene Personen gleichzeitig (unabhängig voneinander) dasselbe Dokument Software(technik)praktikum: Vorlesung 2: Versionsmanagement

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? Software(technik)praktikum: Vorlesung 2: Versionsmanagement

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 Software(technik)praktikum: Vorlesung 2: Versionsmanagement

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! Software(technik)praktikum: Vorlesung 2: Versionsmanagement

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) Software(technik)praktikum: Vorlesung 2: Versionsmanagement

8. Versionsmanagement Konzepte Repository Dokumente in hierarchischer Struktur Koordination der Zugriffe und Modifikationen, insbes. Wahrung der Konsistenz Versions-verwaltungs-system Zugriff und Modifikation von Dokumenten Nutzer Nutzer Software(technik)praktikum: Vorlesung 2: Versionsmanagement

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) Software(technik)praktikum: Vorlesung 2: Versionsmanagement

10. Optimistischer Ansatz Repository Versions-verwaltungs-system Lokale Kopien desRepositories (Arbeitsverzeichnis) Nutzer Nutzer Software(technik)praktikum: Vorlesung 2: Versionsmanagement

11. Pessimistischer Ansatz Zwischen checkout und checkinkannkeinandererNutzer die Dateiverändern. • Ablauf zur Bearbeitung einer Datei file.txt: checkout file.txt < Bearbeitung der Datei > checkin file.txt Genaue Syntax und Optionen der KommandoshängenvomVersionsverwaltungssystem ab. Software(technik)praktikum: Vorlesung 2: Versionsmanagement

12. 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 commitsind (nahezu) jederzeit erlaubt Genaue Syntax und Optionen der KommandoshängenvomVersionsverwaltungssystem ab. Software(technik)praktikum: Vorlesung 2: Versionsmanagement

13. Optimistischer AnsatzMischen (Merge): Szenario 1 file.txt file.txt file.txt Änderungen im Repository(durch commit anderer Benutzer) Änderungen im Arbeitsverzeichnis Software(technik)praktikum: Vorlesung 2: Versionsmanagement

14. Optimistischer AnsatzMischen (Merge): Szenario 1 file.txt file.txt update (+ ggf. merge) Merge: Änderungen aus dem Repository (seit der letzten Aktualisierung) und der Änderungen im lokalen Verzeichnis Änderungen im Repository Aktualisierte Version imArbeitsverzeichnis 14 Software(technik)praktikum: Vorlesung 2 Software(technik)praktikum: Vorlesung 2: Versionsmanagement

15. Optimistischer AnsatzMischen (Merge): Szenario 1 file.txt BeigängigenSystemenfunktioniert das erstmalnurmit Text-Dateien (z.B. .java oder .tex) file.txt update Änderungen im Repository Aktualisierte Version imArbeitsverzeichnis Software(technik)praktikum: Vorlesung 2: Versionsmanagement

16. Optimistischer AnsatzMischen (Merge): Szenario 2 file.txt file.txt file.txt Änderungen im Repository Änderungen im Arbeitsverzeichnis Software(technik)praktikum: Vorlesung 2: Versionsmanagement

17. Optimistischer AnsatzMischen (Merge): Szenario 2 file.txt file.txt file.txt Konflikt update Änderungen im Repository Änderungen im Arbeitsverzeichnis Software(technik)praktikum: Vorlesung 2: Versionsmanagement

18. Optimistischer AnsatzKonflikte • Konflikte werden in der Datei im Arbeitsverzeichnis markiert: <<<<<< Änderung 1 ------ Änderung 2 >>>>>> • Konflikte müssen vom Benutzer in seiner Arbeitskopie von Hand korrigiert werden. • Hinweis: Konflikte entstehen nur Arbeitsverzeichnis Software(technik)praktikum: Vorlesung 2: Versionsmanagement

19. Optimistischer AnsatzMergen 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 Software(technik)praktikum: Vorlesung 2: Versionsmanagement

20. 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 Software(technik)praktikum: Vorlesung 2: Versionsmanagement

21. Optimistischer Ansatz Commit-Unterbindung v100 Versions-verwaltungs-system v100 v100 Software(technik)praktikum: Vorlesung 2: Versionsmanagement

22. Optimistischer Ansatz Commit-Unterbindung v100 Versions-verwaltungs-system v100* v100* v100 Software(technik)praktikum: Vorlesung 2: Versionsmanagement

23. Optimistischer Ansatz Commit-Unterbindung v101 > commit > commit up-to-datecheck failed Versions-verwaltungs-system v100* v101 Software(technik)praktikum: Vorlesung 2: Versionsmanagement

24. Optimistischer Ansatz Commit-Unterbindung v101 > commit > commit up-to-datecheck failed > update Mfile.txt Versions-verwaltungs-system v100* v101* v101 Software(technik)praktikum: Vorlesung 2: Versionsmanagement

25. Optimistischer Ansatz Commit-Unterbindung v102 > commit v101 > commit up-to-datecheck failed > update Mfile.txt Versions-verwaltungs-system > commit v101* v102 v101 Software(technik)praktikum: Vorlesung 2: Versionsmanagement

26. Unterstützung für Versions-management in Eclipse 26 Software(technik)praktikum: Vorlesung 2 Software(technik)praktikum: Vorlesung 2: Versionsmanagement

27. 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 Software(technik)praktikum: Vorlesung 2: Versionsmanagement

28. VersionierungsartRepository-Versionierung Repository-Versionierung • Je commit gibt es eine neue Repository-Nummer • Head ist neueste Repository-Version <<changed>> <<added>> Main.java Appl.java V4 >>commit <<added>> V3 main.html >>commit <<added>> V2 index.html >>commit <<added>> Main.java V1 >>commit Software(technik)praktikum: Vorlesung 2: Versionsmanagement

29. VersionierungsartDateiversionierung Dateiversionierung • JedeDatei hat ihreeigene 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 Software(technik)praktikum: Vorlesung 2: Versionsmanagement

30. 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) Software(technik)praktikum: Vorlesung 2: Versionsmanagement

31. 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 Software(technik)praktikum: Vorlesung 2: Versionsmanagement

32. Inhalt für das Repository • Welche Dokumente und Dateien gehören ins Repository? • AlleDokumente 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 …) Software(technik)praktikum: Vorlesung 2: Versionsmanagement

33. Praktikum: SVN • Im Praktikumnutzenwir 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. • Subclipseund Subversive für Eclipse • TortoiseSVN • Integriert sich in Windows-Explorer Software(technik)praktikum: Vorlesung 2: Versionsmanagement

34. 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 http://commons.wikimedia.org/wiki/File:Subversion_project_visualization.svg Software(technik)praktikum: Vorlesung 2: Versionsmanagement

35. 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 Software(technik)praktikum: Vorlesung 2: Versionsmanagement