KONFIGURATIONSVERWALTUNG0...

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



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


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


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


43

Beispiele


44

Beispiele


45

Beispiele


46

Kapitelübersicht



Versionsverwaltung

47

Der heuOge Standard: zentralisierte Versionskontrolle

Quelle: Scott Chacon: Pro Git (http://git-scm.com/book)

48

Der neue Trend: verteilte Versionskontrollsysteme


49

Der neue Trend: verteilte Versionskontrollsysteme


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


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


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


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


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


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


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


79


80


81


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.

86


87


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.

89


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


91


92



93



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.

KONFIGURATIONSVERWALTUNG0...

Documents

Transcript of KONFIGURATIONSVERWALTUNG0...