Post on 14-Aug-2020
So#waretechnik
Prof. Dr. Wolfgang Schramm
KONFIGURATIONSVERWALTUNG Kapitel 7
1
Übersicht
1. Einführung in das SoDware Engineering
2. SoDwareprozesse 3. Anforderungsanalyse und -‐
SpezifikaOon 4. SoDwareentwurf 5. Programmierung 6. SoDware-‐Qualitätssicherung und -‐
Prüfung 7. KonfiguraOonsverwaltung 8. SoDware-‐Wartung
2
Ziele
¨ Sie wissen um die Bedeutung des KonfiguraOonsmanagement in Entwicklungsprojekten.
¨ Sie kennen die grundlegenden Begriffe und Aufgaben des KonfiguraOons-‐management.
¨ Sie kennen den Zusammenhang gibt es zwischen KonfiguraOons-‐management und Versionsverwaltung.
3
Kapitelübersicht
1. Einführung & Begriffe Grundlagen der Versionsverwaltung
2. Aufgaben 3. Zentrale vs. Verteilte
Versionsverwaltung
4
Wozu KonfiguraOonsmanagement?
o „Ändern Sie noch eben schnell..." o Die (allzu einfache) Möglichkeit, SoDware zu ändern,
verursacht eine Menge von Problemen. ¤ Zum Beispiel:
n Codieren anhand der falschen Version des Entwurfs. n Paralleles, unkoordiniertes Ändern eines Moduls durch mehrere Personen. n UndokumenOerte Schnellreparaturen an in Betrieb befindlicher SoDware.
o Oder Jahre später in der Wartung eines 10 Jahre alten Codes ¤ Ein Kunde hat noch Änderungswünsche/Fehler in einer alten, längst
weiterentwickelten Version, will aber nicht zu einer neueren wechseln.
¤ Keiner der Entwickler kennt sich mit dem Code noch aus.
5
MoOvaOon
o Produkt-‐Auslieferung an einen Kunden ¤ … und es funkOoniert bei ihm nicht! ¤ Fälschlicherweise wurde bei einer Komponente die (instabile)
Entwicklerversion geliefert
o Zwei Entwickler arbeiten an der gleichen Komponente ¤ … doch am Ende ist nur die Arbeit des einen in der neuen Komponente
enthalten ¤ Dummerweise hat ein Entwickler die Änderungen des anderen
überschrieben
o Die neue Version soll getestet werden ¤ … doch die mühevoll erstellten Testdaten sind verschwunden ¤ Sie wurden beim „Aufräumen“ gelöscht
6
DefiniOonen 1/7
o KonfiguraOonselement ¤ Jedes Artefakt, das im Laufe der Entwicklung entsteht, für Entwicklung, Wartung oder Betrieb relevant ist, und unter KonfiguraOonsmanagement gestellt wird Es ist n unabhängig von anderen KonfiguraOonselementen bearbeitbar, n nicht weiter zerlegbar (bzw. wird nicht weiter zerlegt)
Beispiele n SpezifikaOon, Code-‐Stücke, Make-‐/Ant-‐/Maven-‐Files n Keine KonfiguraOonselemente sind
n (Sitzungs-‐)Protokolle, NoOzen
7
DefiniOonen 2/7
o Version ¤ Eine idenOfizierbare Instanz eines KonfiguraOonselements ¤ Beispiel sort wird zum SorOeren von Dateien verwendet; mit sort_1.1 können Dateien sorOert werden; in sort_1.2 werden auch leere Dateien korrekt behandelt
Anmerkung n “idenOfizierbar” bedeutet
n hat einen Namen (z.B. siehe oben: sort_1.2) n exisOert jederzeit bzw. kann jederzeit wiederhergestellt werden (z.B.
schreibgeschützte Datei)
8
Einführung ■■■ Aufgaben ■■■ Zentrales vs. verteiltes KM
DefiniOonen 3/7
Beziehungen zwischen Versionen o revision-‐of
¤ Eine neue Version ersetzt die Vorgängerversion ¤ Beispiel sort_1.2 entsteht aus sort_1.1, in dem auch leere Dateien korrekt behandelt werden
o variant-‐of ¤ Die neue Version erfüllt weitere Anforderungen ¤ Beispiel sort_1.2a entsteht aus sort_1.2, um die spezielle Schlüsselstruktur von Kunde A zu berücksichOgen.
o Variante ¤ Eine Variante ist eine neue Version, die in der Beziehung “variant-‐of” zur alten Version steht
9
Beziehung zwischen Versionen
V1 V2 V3
Quelle: Ludewig, Lichter: Software Engineering, dpunkt, Heidelberg, 2007
V2a V3a
V2b V3b
X1 X2
Y1 Y2
Variante
t
variant-of
revision-of
Version
10
DefiniOonen 4/7
o Codelinie (code line) ¤ TransiOve Hülle der revision-‐of-‐RelaOon Anmerkung
n Eine Codelinie beginnt mit der iniOalen Version oder einer Variante
o Variantenfamilie ¤ TransiOve Hülle der revision-‐of-‐ und variant-‐of-‐RelaOon Anmerkung
n Eine Variantenfamilie beginnt mit der iniOalen Version
11
Codelinie/Variantenfamilie
V1 V2 V3
Quelle: Ludewig, Lichter: Software Engineering, dpunkt, Heidelberg, 2007
V2a V3a
V2b V3b
X1 X2
Y1 Y2 Codelinie
Variantenfamilie
t
12
DefiniOonen 5/7
o KonfiguraOon ¤ Menge von KonfiguraOonselementen, die gemeinsam (ein funkOonierendes) System bilden. Typischerweise enthält eine KonfiguraOon höchstens ein KonfiguraOonselement aus einer Variantenfamilie.
13
KonfiguraOonen
Quelle: Kleuker: Grundkurs Software Engineering mit UML, Vieweg+Teubner, Wiesbaden, 2011 (modifiziert)
SW-Einheit 1
SW-Einheit 2
SW-Einheit 3
V1 V2 V3 V4 V5
X1 X2 X3 X4
X2a X3a
Y1 Y2 Y3
Y2a Y3a
Y2aα Y2aβ
Konfiguration 1 Konfiguration 2
15
DefiniOonen 6/7
o Baseline ¤ speziell ausgezeichnete, stabile KonfiguraOon, die als Ausgangspunkt
für die Weiterentwicklung dient
o Release ¤ speziell ausgezeichnete, stabile KonfiguraOon, die an Kunden
(allgemein: Stakeholder) ausgeliefert wird
16
Release
o Ein Release enthält typischerweise ¤ SoDware (Programme, Bibliotheken) ¤ Daten, die für einen erfolgreichen Betrieb nöOg sind
n Beispiel: Fehlertext-‐Dateien, IniOalisierungsdateien ¤ InstallaOonsprogramm ¤ Systemhandbuch (einschl. Systemvoraussetzungen),
Benutzerhandbuch ¤ Produktwerbung
o Typische Bezeichnung ¤ x.y.z
Patch Wartungsrelease Hauptrelease
17
DefiniOonen 7/7
o KonfiguraOons-‐Versionen, -‐Varianten Release-‐Versionen, -‐Varianten ¤ analog zu KonfiguraOonselement-‐Versionen, -‐Varianten
o KonfiguraOonsmanagement ¤ ist die Rolle/OrganisaOonseinheit, die die KonfiguraOonselemente und
KonfiguraOonen idenOfiziert, verwaltet und bereitstellt, sowie deren Änderungen überwacht und dokumenOert.
18
Kapitelübersicht
1. Einführung & Begriffe Grundlagen der Versionsverwaltung
2. Aufgaben 3. Zentrale vs. Verteilte
Versionsverwaltung
19
Aufgaben (1)
Versionen
Quelle: Sommerville: Software Engineering, Pearson, Boston, 2011 (modifiziert)
Configuration Elements
20
Aufgaben (2)
o Version Management Versionsmanagement ¤ Verwalten verschiedener Versionen eines KonfiguraOonselements ¤ Ermöglichen paralleler Änderungen
o Release Management Releasemanagement ¤ Zusammenstellen von Releases ¤ Verwalten ausgelieferter Releases
o System Building KonstrukOon ausführbarer Systeme ¤ Zusammenstellen von lauffähigen Systemen aus verschiedenen
KonfiguraOonen
o Change Management Änderungsmanagement ¤ Verwalten von Änderungswünschen ¤ SystemaOsches Bewerten von und Entscheiden über Änderungen
im Folgenden näher betrachtet
Tools: Git, Subversion (SVN)
Tools: maven, ant
22
Repository
o Ein Verzeichnisbaum (Repository) enthält alle Dateien, die zu einem Programm gehören.
o Im Repository befinden sich alle gespeicherten Dateien unter Versionsverwaltung.
o Das Repository ist in der Lage, alle vergangenen Änderungen der Dateien und Verzeichnisse abzurufen.
o Verwaltet wird nicht nur Programmcode, sondern auch Anforderungsdokumente, Designdokumente, Benutzerdokumen-‐taOon etc.
23
Versionsmanagement – Repository (1)
o enthält alle Versionen ¤ eine
kompleve Datei
¤ Deltas
Quelle: G. Popp: Konfigurationsmanagement, dpunkt, 2006
24
Versionsmanagement – Repository (2)
o Inhalt für KonfiguraOonselement ¤ Daten ¤ Versionsnummer ¤ Status
¤ Tags n z.B. um Zugehörigkeit zu Baseline/Release zu kennzeichnen
¤ Änderungshistorie
freigegeben
verworfen
ungeprüft
erfo
lgre
ich
gepr
üft
geän
dert
Aufnahme in Baseline/ Release
25
Versionsmanagement – Projektstruktur (1)
können gelöscht werden, da der Inhalt wieder generiert werden
kann Quelle: G. Popp: Konfigurationsmanagement, dpunkt, 2006
26
Versionsmanagement – Projektstruktur (2)
Aufsplitten bei größeren Projekten
Quelle: G. Popp: Konfigurationsmanagement, dpunkt, 2006
27
Durch-‐ führen
von Ände-‐ rungen
– Ablauf
Quelle: G. Popp:
Konfigurations- management, dpunkt, 2006
28
Konzepte
o Eine beliebige Anzahl von Clients kann sich mit dem Repository verbinden und Dateien lesen oder schreiben.
o Die Clients können die Daten anderen zugänglich machen, indem sie die Daten ins Repository schreiben.
o Geänderte Dateien werden nach korrektem Abschluss der Änderungen kommenOert mit neuer Versionsnummer wieder ins Repository gestellt (check in/commit).
29
Probleme beim Filesharing
30
Konzepte
o Arbeitsmodelle der Versionsverwaltung ¤ Lock-‐Modify-‐Unlock ¤ Copy-‐Modify-‐Merge
31
Lock-‐Modify-‐Unlock
o Wird auch als pessimisEsche Versionskontrolle bezeichnet ¤ Einzelne Dateien müssen vor einer Änderung
durch den Benutzer gesperrt werden. ¤ Während sie gesperrt sind, verhindert das
System Änderungen anderer Benutzer, die warten müssen.
¤ Nach Abschluss der Änderung werden die gesperrten Dateien wieder freigegeben.
32
Lock-‐Modify-‐Unlock
33
Bekannte Probleme mit Sperren
o Verwaltungsproblem: ¤ Wenn eine Datei von einem Benutzer gesperrt wurde, und er
vergessen hat, die Datei wieder freizugeben.
o UnnöOge Serialisierung: ¤ Wenn die Benutzer verschiedene unwidersprüchliche Teile der Datei
gleichzeiOg bearbeiten wollen.
o Falsches Sicherheitsgefühl: ¤ Wenn die Benutzer verschiedene Dateien bearbeiten, die aber eine
Abhängigkeit voneinander haben
34
Copy-‐Modify-‐Merge
o Wird auch als opEmisEsche Versionskontrolle bezeichnet ¤ Das Arbeitskopiekonzept wird benutzt, um das Sperren zu vermeiden. ¤ Die Benutzer erstellen ihre eigenen lokalen Arbeitskopien
(Spiegelkopie vom Server), wo sie parallel mit vollen Schreibrechten arbeiten.
¤ Die Benutzer vom Versionsverwaltungssystem werden unterstützt, ihre Änderungen mit dem Gesamtversion des Repositorys zu vereinen.
¤ Die Konflikte, die nicht automaOsch vom Versionsverwaltungssystem gelöst werden, müssen die Benutzer selber lösen.
35
Copy-‐Modify-‐Merge
36
Copy Modify Merge
37
Durchführen von Änderungen -‐ Befehle
o check-‐out ¤ Bereitstellen einer Kopie zum Bearbeiten im Arbeitsbereich
o update ¤ Aktualisieren der Kopie im Arbeitsbereich (vom Repository)
o check-‐in ¤ Einbringen der bearbeiteten als neue Version ins Repository
o commit ¤ Einbringen der aktuellen Änderungen ins Repository
o revert ¤ Änderungen verwerfen (nur vor commit/check-‐in möglich)
38
Durchführen von Änderungen – Parallele Verarbeitung
o Idee ¤ Mehrere Entwickler können parallel (gleichzeiOg) an einem Modul
(KonfiguraOonselement) arbeiten
o Problem ¤ Entwickler können gleiche (Code-‐)Teile verschieden geändert haben
o Strategien für parallele Bearbeitung n Lock-‐Modify-‐Unlock
n nur sequenOelle Bearbeitung, keine Konflikte möglich
n Copy-‐Modify-‐Merge n parallele Bearbeitung möglich, Konflikte möglich
Entwickler sollten sich absprechen, damit nicht gleiche Codeteile geändert werden
39
Durchführen von Änderungen -‐ Konfliktbehebung
o Konflikt ¤ Zwei Entwickler ändern gleiche Klasse (KonfiguraOonselement)
o Konfliktbehebung ¤ einfache Konflikte: automaOsch
n Änderungen in verschiedenen Codezeilen n beheben:
n automaOsch beide Änderungen übernehmen n neue Version überprüfen
¤ ernste Konflikte: manuell n Änderungen der gleichen Codezeilen n beheben:
n erste/zweite/alle Änderungen verwerfen oder n manuell zusammenführen
40
Durchführen von Änderungen – Branch/Merge
Verzweigung Branch
Zusammenführung Merge
41
Beispiele
http://betterexplained.com/articles/a-visual-guide-to-version-control/
42
Beispiele
http://betterexplained.com/articles/a-visual-guide-to-version-control/
43
Beispiele
http://betterexplained.com/articles/a-visual-guide-to-version-control/
44
Beispiele
http://betterexplained.com/articles/a-visual-guide-to-version-control/
45
Beispiele
http://betterexplained.com/articles/a-visual-guide-to-version-control/
46
Kapitelübersicht
1. Einführung & Begriffe Grundlagen der Versionsverwaltung
2. Aufgaben 3. Zentrale vs. Verteilte
Versionsverwaltung
47
Der heuOge Standard: zentralisierte Versionskontrolle
Quelle: Scott Chacon: Pro Git (http://git-scm.com/book)
48
Der neue Trend: verteilte Versionskontrollsysteme
Quelle: Scott Chacon: Pro Git (http://git-scm.com/book)
49
Der neue Trend: verteilte Versionskontrollsysteme
Quelle: Scott Chacon: Pro Git (http://git-scm.com/book)
optional möglich
50
Der Trend? Suchanfragen bei Google
SVN GIT
51
Noch Fragen?
51
52
Konfigura@onsmanagement
o KonfiguraEonsmanagement: ist die Gesamtheit aller Verfahren zur eindeuOgen Kennzeichnung der KonfiguraOon eines SoDware-‐Systems mit dem Zweck, den Auyau und alle Änderungen dieser KonfiguraOon systemaOsch zu überwachen, die Konsistenz des SoDware-‐Systems sicher-‐zustellen und die Möglichkeit der Rückverfolgung anzubieten.
53
Neue Begriffe!
o Konfigura@onsmanagement: ist die Gesamtheit aller Verfahren zur eindeuOgen Kennzeichnung der KonfiguraEon eines SoDware-‐Systems mit dem Zweck, den Auyau und alle Änderungen dieser KonfiguraOon systemaOsch zu überwachen, die Konsistenz des SoDware-‐Systems sicherzustellen und die Möglichkeit der Rückverfolgung anzubieten.
54
Begriffe
o Eine So$ware-‐KonfiguraEon ist eine Menge zusammenpassender SoDware-‐Einheiten.
o Eine So$ware-‐Einheit ist der kleinste, im Rahmen der KonfiguraOonsverwaltung als atomar behandelte Baustein einer KonfiguraOon. SoDware-‐Einheiten werden nur als Ganzes registriert, freigegeben oder geändert. SoDware-‐Einheiten sind z.B. Programm-‐Module und Dokumente.
o Also: n Es werden also alle Teile der SoDware – Programme, Abläufe, Regeln, auch DokumentaOon und Daten, die mit dem Betrieb des Rechnersystems zu tun haben, verwaltet.
n Das KonfiguraOonsmanagement erstreckt sich über den gesamten SoDware-‐Lebenszyklus.
55
Begriffe
o SoDware-‐Einheiten ändern sich über die Zeit. o Aus einer SoDware-‐Einheit entsteht eine neue Version, wenn
eine Änderung durchgeführt wird, die die Einheit besser macht (Korrektur, Erweiterung, Anpassung, etc.)
o Von jeder Einheit können mehrere Versionen geführt werden. Im einfachsten Fall wird durch aufsteigende Versionsnummern deutlich gemacht, in welcher Reihenfolge die Versionen entstanden sind.
V1 V2 V3
Zeit
56
Revisionen und Varianten
o Varianten stehen zeitlich nicht hintereinander, sondern nebeneinander.
V1 V2 V3
Zeit
V2a
V2b
V3a
V3b
57
Revisionen und Varianten
o Revisionen ¤ Eine neue Version ersetzt die Vorgängerversion. ¤ Revisionen entsteht durch Überarbeitung. ¤ Beispiel sort_1.2 entsteht aus sort_1.1, in dem auch leere Dateien korrekt behandelt werden
o Varianten ¤ Die neue Version erfüllt weitere Anforderungen. Varianten haben gemeinsame EigenschaDen und in der Regel eine gemeinsame Vorgängerversion
¤ Beispiel sort_1.2a entsteht aus sort_1.2, um die spezielle Schlüsselstruktur von Kunde A zu berücksich@gen.
58
Zurück zur KonfiguraOon
Konfiguration 2
Konfiguration 1
SW-Einheit 1
SW-Einheit 2
SW-Einheit 3
Quelle: Kleuker: Grundkurs Software Engineering mit UML, Vieweg+Teubner, Wiesbaden, 2011 (modifiziert)
60
Aufgaben der KonfiguraOonsverwaltung
o Versionskontrolle ¤ SoDware Einheiten sind eindeuOg idenOfiziert. ¤ Die erstellten Versionen/Varianten werden über lange Zeiträume
verwaltet. ¤ Ein Zugriff ist jederzeit möglich.
n Idee: Zeitmaschine
o KonfiguraOonskontrolle ¤ Es können beliebige KonfiguraOonen des SoDware Systems mit genau
definierten EigenschaDen erstellt werden, wenn die Komponenten vorliegen.
¤ Es ist sichergestellt, dass alle Bestandteile einer KonfiguraOon konsistent sind. n Vermeidet Fehler durch Inkonsistenz.
61
Aufgaben der KonfiguraOonsverwaltung
o KonstrukOon ausführbarer Programme ¤ Der Prozess, um aus Quellcode ausführbare Programme zu erzeugen
(Build-‐Prozess), wird mit den KonfiguraOonsinformaOonen gesteuert und ist automaOsiert. n Effizienzsteigerung
o Änderungskontrolle ¤ Alle Änderungen an SoDware-‐Einheiten werden überwacht, alle
Prüfresultate verwaltet n Qualitätssteigerung, nicht jeder kann/darf alles ändern, freigeben. ... n DokumentaOon der Vorgänge
62
Aufgaben der KonfiguraOonsverwaltung
o KoordinaOon der Teamarbeit ¤ Die Zusammenarbeit der Entwickler wird durch gemeinsame
Referenzumgebungen und durch die Konflikterkennung oder-‐vermeidung unterstützt.
¤ Zugriffskontrolle, nicht jeder sieht alles
o Also: n KonfiguraOonsverwaltung schließt die Versionsverwaltung ein. n Begriffliche Trennung/Verwendung in der Praxis meist unsauber.
63
KonfiguraOonsmanagement in verschiedenen Prozessen
o In der inkrementellen Entwicklung ¤ mit täglichem Built-‐Prozess ¤ Mit nebenläufigem Entwicklungs-‐ und Testprozess. ¤ Entwickler liefern neue Komponenten zu einer festen Uhrzeit. ¤ Durch Kompilieren und Linken wird aus diesen neuen Komponenten
eine neue Version der SoDware erzeugt. ¤ Die neue Version wird zum Tesveam weitergereicht. ¤ Das Entwicklungsteam entwickelt weiter. ¤ Fehler werden vom Tesveam an das Entwicklungsteam
zurückgemeldet und vom Entwicklungsteam in der Folgeversion behoben.
64
Kapitelübersicht
1. Einführung & Begriffe 2. Grundlagen der Versions-‐
verwaltung § Repository & Arbeitsmodelle § Grundlegende Befehle
3. Werkzeuge § Zentralisierte Versionsverwaltung § Verteilte Versionsverwatlung
65
Konzepte
o Zusammenarbeiten & Beiträge bringen ¤ Aber die Beiträge sollten organisiert werden, um Konflikte und
Nacharbeit zu vermeiden. ¤ Wie können die Benutzer zusammenarbeiten und InformaOonen
abrufen, ohne Konflikte hervorzurufen?
66
Konzepte
o Ein Verzeichnisbaum (Repository) enthält alle Dateien, die zu einem Programm gehören.
o Im Repository befinden sich alle gespeicherten Dateien unter Versionsverwaltung.
o Das Repository ist in der Lage, alle vergangenen Änderungen der Dateien und Verzeichnisse abzurufen.
o Verwaltet wird nicht nur Programmcode, sondern auch Anforderungsdokumente, Designdokumente, Benutzerdokumen-‐taOon etc.
67
Konzepte
o Eine beliebige Anzahl von Clients kann sich mit dem Repository verbinden und Dateien lesen oder schreiben.
o Die Clients können die Daten anderen zugänglich machen, indem sie die Daten ins Repository schreiben.
o Geänderte Dateien werden nach korrektem Abschluss der Änderungen kommenOert mit neuer Versionsnummer wieder ins Repository gestellt (check in/commit).
68
Probleme beim Filesharing
69
Konzepte
o Arbeitsmodelle der Versionsverwaltung ¤ Lock-‐Modify-‐Unlock ¤ Copy-‐Modify-‐Merge
70
Lock-‐Modify-‐Unlock
o Wird auch als pessimisEsche Versionskontrolle bezeichnet ¤ Einzelne Dateien müssen vor einer Änderung
durch den Benutzer gesperrt werden. ¤ Während sie gesperrt sind, verhindert das
System Änderungen anderer Benutzer, die warten müssen.
¤ Nach Abschluss der Änderung werden die gesperrten Dateien wieder freigegeben.
71
Lock-‐Modify-‐Unlock
72
Bekannte Probleme mit Sperren
o Verwaltungsproblem: ¤ Wenn eine Datei von einem Benutzer gesperrt wurde, und er
vergessen hat, die Datei wieder freizugeben.
o UnnöOge Serialisierung: ¤ Wenn die Benutzer verschiedene unwidersprüchliche Teile der Datei
gleichzeiOg bearbeiten wollen.
o Falsches Sicherheitsgefühl: ¤ Wenn die Benutzer verschiedene Dateien bearbeiten, die aber eine
Abhängigkeit voneinander haben
73
Copy-‐Modify-‐Merge
o Wird auch als opEmisEsche Versionskontrolle bezeichnet ¤ Das Arbeitskopiekonzept wird benutzt, um das Sperren zu vermeiden. ¤ Die Benutzer erstellen ihre eigenen lokalen Arbeitskopien
(Spiegelkopie vom Server), wo sie parallel mit vollen Schreibrechten arbeiten.
¤ Die Benutzer vom Versionsverwaltungssystem werden unterstützt, ihre Änderungen mit dem Gesamtversion des Repositorys zu vereinen.
¤ Die Konflikte, die nicht automaOsch vom Versionsverwaltungssystem gelöst werden, müssen die Benutzer selber lösen.
74
Copy-‐Modify-‐Merge
75
Copy Modify Merge
76
Inhalt
o Einführung/Begriffe o Grundlagen der Versionsverwaltung
¤ Repository & Arbeitsmodelle ¤ Grundlegende Befehle
o Werkzeuge ¤ Zentralisierte Versionsverwaltung ¤ Verteilte Versionsverwaltung
77
Durchführen von Änderungen -‐ Befehle
o check-‐out ¤ Bereitstellen einer Kopie zum Bearbeiten im Arbeitsbereich
o update ¤ Aktualisieren der Kopie im Arbeitsbereich (vom Repository)
o check-‐in/commit ¤ Einbringen der bearbeiteten als neue Version ins Repository
o revert ¤ Änderungen verwerfen (nur vor commit/check-‐in möglich)
78
http://betterexplained.com/articles/a-visual-guide-to-version-control/
79
http://betterexplained.com/articles/a-visual-guide-to-version-control/
80
http://betterexplained.com/articles/a-visual-guide-to-version-control/
81
http://betterexplained.com/articles/a-visual-guide-to-version-control/
83
Inhalt
o Einführung/Begriffe o Grundlagen der Versionsverwaltung
¤ Repository & Arbeitsmodelle ¤ Grundlegende Befehle
o Werkzeuge ¤ Zentralisierte Versionsverwaltung ¤ Verteilte Versionsverwatlung
84
Konzepte der Versionsverwaltung
Zentrale Versionsverwaltung ¤ als Client-‐Server-‐System ¤ Zugriff auf ein Repository kann auch über Netzwerk erfolgen. ¤ Durch eine Rechteverwaltung wird dafür gesorgt, dass nur berechOgte
Personen neue Versionen in das Archiv legen können. ¤ Die Versionsgeschichte ist hierbei nur im Repository vorhanden. ¤ Bsp: (CVS) populär gemacht, mit Subversion (SVN) ¤ Grundlegende Elemente:
n Working Set/Working Copy: Your local directory of files, where you make changes.
n Trunk/Main: The primary locaOon for code in the repo. Think of code as a family tree — the trunk is the main line.
85
86
http://betterexplained.com/articles/a-visual-guide-to-version-control/
87
Konzepte der Versionsverwaltung
Verteilte Versionsverwaltung ¤ Jeder hat sein eigenes Repository und kann dieses mit jedem
beliebigen anderen Repository abgleichen. ¤ Die Versionsgeschichte ist ebenso verteilt. ¤ Im Gegensatz zur zentralen Versionsverwaltung kommt es nicht zu
einem Konflikt, wenn mehrere Benutzer dieselbe Version einer Datei ändern. Die sich widersprechenden Versionen exisOeren zunächst parallel und können weiter geändert werden.
¤ Verteilte Versionsverwaltungen haben keine Locks. Da wegen der höheren Zugriffsgeschwindigkeit die Granularität der gespeicherten Änderungen viel kleiner sein kann, können sie sehr leistungsfähige, weitgehend automaOsche Merge-‐Mechanismen zur Verfügung stellen.
88
89
Konzepte der Versionsverwaltung
o Verteilte Versionsverwaltung ¤ Verteilte Versionsverwaltung fokusiert darauf, Änderungen zu teilen. ¤ Eine Änderung runterladen und anwenden sind unterschiedliche
Schrive (in in zentraler Versionsverwaltung finden Sie zusammen stav).
¤ Verteilte Versionsverwaltungssysteme haben keine erzwungene Struktur. Es kann zentrale Orte geben oder jeder ist gleichberechOgt.
¤ Neue Begriffe n push: send a change to another repository (may require permission) n pull: grab a change from a repository
90
Verteilte Versionsverwaltung
http://betterexplained.com/articles/a-visual-guide-to-version-control/
91
http://betterexplained.com/articles/a-visual-guide-to-version-control/
92
Verteilte Versionsverwaltung
http://betterexplained.com/articles/a-visual-guide-to-version-control/
93
Verteilte Versionsverwaltung
http://betterexplained.com/articles/a-visual-guide-to-version-control/
94
Werkzeuge
o Zentrale Versionsverwaltung ¤ CVS ¤ SVN
o Verteilte Versionsverwaltung ¤ Bazaar ¤ Darcs ¤ Git ¤ GNU arch ¤ Mercurial ¤ Monotone
95
Zusammenfassung
o Sie können die Begriffe Version, Revision, SoDware Einheit, KonfiguraOon, etc. einordnen
o Sie kennen die grundliegenden Arbeitsmodelle (Lock-‐Modify-‐Merge // Copy-‐Modify-‐Merge)
o Sie kennen die grundlegenden Befehle und den Auyau eines zentralen und verteilten Versionsverwaltungswerkzeugs.