Versionsmanagement. Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn

Transkript

1 Versionsmanagement 1

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

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

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? 4

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 5

6 Versionsmanagement Motivation Einfache Lösungen erzeugen neue Probleme 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! 6

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

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

9 Konsistenzmechanismen Optimistische Mechanismen System erlaubt gleichzeitiges Bearbeiten des Dokuments durch verschiedene 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 verschiedene Personen (Sperrprotokolle) Beide Mechanismen haben Vor- und Nachteile (hierzu später mehr) 9

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

11 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. 11

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 commit sind (nahezu) jederzeit erlaubt Genaue Syntax und Optionen der Kommandos hängen vom Versionsverwaltungssystem ab. 12

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

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

15 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 Änderungen im Repository update Aktualisierte Version im Arbeitsverzeichnis 15

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

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

18 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 im Arbeitsverzeichnis 18

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

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 20

21 Optimistischer Ansatz Commit-Unterbindung v100 v100 Versionsverwaltungssystem v100 21

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

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

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

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

26 Unterstützung für Versionsmanagement in Eclipse Software(technik)praktikum: Vorlesung 3: 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 27

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

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

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) 30

31 Weitere Features von Versionsmanagementsystemen Commit-Kommentar Mit jedem Commit kann (und sollte) man in einem kurzen Kommentar angeben, welche Änderungen vorgenommen wurden Mailbenachrichtigung 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 Feature-Requests können sich auf Versionsnummern beziehen 31

32 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 ) 32

33 Praktikum: SVN Im Praktikum nutzen wir optimistische Mechanismen Konkret: Subversion (SVN) Features: Commit-Kommentare Mailbenachrichtigung bei jedem Check-In Blame-Analyse Verknüpfbar mit Ticketmanagementsystem (z.b. Trac) Viele SVN-Clients, u.a. Subversive (oder Subclipse) für Eclipse TortoiseSVN Integriert sich in Windows-Explorer 33

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 34

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 die Tutorials im Web 35