ClearCase

Vorlesung „Softwaretechnologie“
Exkurs
u s zuu Kapitel
ap te 2: So
Software
t a e Co
Configuration
gu at o Management
a age e t
Exkurs: Clear Case
Dieser Foliensatz enthält Details zu ClearCase.
Ab WS 2009 sind die hier enthaltenen Folien nicht mehr Teil des Prüfungsstoffes sondern
lediglich Vertiefung für Interessierte.
ROOTS
ClearCase® Architektur
Anwendungen mit Dateizugriff
Multiversion
File System
y
Dateisystem von Windowns / UNIX
ClearCase MVFS
Nicht-versionierte
Dateien
© 2000-2009 Dr. G. Kniesel
Cl C
ClearCase
VOB
Vorlesung „Softwaretechnologie“ (SWT)
Exkurs „ClearCase“, Seite 2
ROOTS
Virtuelles Dateien System (Virtual File System) bei
ClearCase
src
foo.h
foo
foo.c
c
VOB
emacs
make
gcc
grep
eclipse
src
foo c
foo.c
Softwareentwicklungswerkzeuge
foo h
foo.h
Versioned Object Base (VOB)
Virtual File System bei ClearCase
src
foo.h
foo
foo.c
c
VOB
emacs
make
gcc
grep
eclipse
WIN
DOWS
/
UNIX
M
V
F
S
src
foo c
foo.c
Softwareentwicklungswerkzeuge
foo h
foo.h
Versioned Object Base (VOB)
ClearCase VOB (Versioned Object Base)
 Sicheres Repository
 aufbauend auf objektorientierter
Datenbank
 Zugriff nur mit ClearCase möglich
 Speichert alle versionierten Daten
0
bugfix
 Source code
0
 Directories
1
 Binaries
 Wer hat was, wann, warum getan?
 Gemeinsamer Datenzugriff
 Beliebig viele VOBs im Netzwerk
2
1
Release 1
2
3
4
develop
0
1
Release 2
4
2
mit beliebig vielen Elementen
 Verteile Datenbank
© 2000-2009 Dr. G. Kniesel
Vorlesung „Softwaretechnologie“ (SWT)
Exkurs „ClearCase“, Seite 5
ROOTS
SCM: Das Fundament des
Entwicklungsprozesses
Analysis
Entwurf
Implementierung
Test
Wartung
Software Configuration Management
V i Control
Version
C
l
B ild Management
Build
M
Workspace Management
Process Control
© 2000-2009 Dr. G. Kniesel
Vorlesung „Softwaretechnologie“ (SWT)
Exkurs „ClearCase“, Seite 6
ROOTS
Workspace Management (1)
 Einrichtung und Pflege einer persönlichen Arbeitsumgebung
 d.h.
dh Z
Zusammenstellung
t ll
d
der b
benötigten
öti t Obj
Objekte
kt
 Sources, Binaries, ...
 ... für die entsprechende Aufgabe
 Bugfixing, Neu- / Weiterentwicklung, …
 Ansätze
 unconstrained:
 keine wohldefinierte Arbeitsumgebung erforderlich
 hierarchical sub-environments:
 vorgegebene Arbeitsbereiche können kopiert und lokal geändert werden
 change sets:
 Grundversion eines Objekts + Menge von Änderungen dieses Objekts
 rule-based environments:
 benötigte Objekte werden über Regeln definiert
© 2000-2009 Dr. G. Kniesel
Vorlesung „Softwaretechnologie“ (SWT)
Exkurs „ClearCase“, Seite 7
ROOTS
Workspace Management: Hierarchical
Sub Environments
Sub-Environments
Vater 1
 Prinzip
Kind 4 = Vater 2
 copy - modify
dif - merge
Kind 1
Kind 2
Kind 3
Kind 5
Kind 6
 Nachteile
 zur Integration von Änderungen muß gemeinsamer "Vater" vorhanden
sein; dieser wird dann unwiderruflich geändert
 paarweiser Austausch zwischen "Kindern"
Kindern nicht direkt möglich
 Kombination von Teilaspekten einzelner "Kinder" nicht möglich
 informative globale Sicht geht durch Isolation der Arbeitsumgebungen
verloren
© 2000-2009 Dr. G. Kniesel
Vorlesung „Softwaretechnologie“ (SWT)
Exkurs „ClearCase“, Seite 8
ROOTS
Workspace Management: Change Sets
 Gruppierung von aufeinander aufbauenden Versionen
 z.B.
B Bugfixes
B fi
 wird oft zur Organisation einer Entwicklungslinie benutzt
 am Ende des Entwicklungsprozesses
g p
werden die kumulativen
Veränderungen als neue Versionen herausgebracht (patch bundles)
© 2000-2009 Dr. G. Kniesel
Vorlesung „Softwaretechnologie“ (SWT)
Exkurs „ClearCase“, Seite 9
ROOTS
Workspace Management: Rule-Based
Workspaces
 Prinzip: regeldefinierte Auswahl von Objekten / Versionen
 Statische Regelauswertung
 Auswertung der Regeln zum Zeitpunkt des Arbeitsbeginns
 ausgewählte Versionen werden in den privaten Arbeitsbereich kopiert
 der Benutzer muss am Ende explizit die Synchronisation anstoßen
 Dynamische Regelauswertung
 Auswertung der Regeln zum Zeitpunkt des Objektzugriffs
 ClearCase
© 2000-2009 Dr. G. Kniesel
Vorlesung „Softwaretechnologie“ (SWT)
Exkurs „ClearCase“, Seite 10
ROOTS
Views in ClearCase (1)
 Configuration Specification
 Sichtdefinition
Si htd fi iti d
durch
hb
benutzerspezifische
t
ifi h Regelmenge
R
l
 agieren als Filter
 Auswahl einer bestimmten Objektversion
j
verhindert Zugriff
g auf alle
anderen Versionen des selben Objekts
 Projektion der ausgewählten Struktur und der spezifizierten Versionen als
normaler Verzeichnisbaum
 nur für den privaten Gebrauch gedacht
© 2000-2009 Dr. G. Kniesel
Vorlesung „Softwaretechnologie“ (SWT)
Exkurs „ClearCase“, Seite 11
ROOTS
ClearCase Views
 Transparentes Arbeiten mit
verschiedenen Releases des
l i h P
j kt
gleichen
Projekts
View
 “Zeig mir Version 2.20”
 Eine Art Filter
 Arbeiten in Echtzeit
 Sofortiger Zugriff auf den
gesamten Datenbestand
 Downloads finden nur statt,
wenn es erforderlich ist (ein
Zugriff)
 kein komplettes Kopieren!
© 2000-2009 Dr. G. Kniesel
Vorlesung „Softwaretechnologie“ (SWT)
Exkurs „ClearCase“, Seite 12
ROOTS
ClearCase Views
 Alle Objekte im VOB sind schreibgeschützt
 Check-Out
Ch k O t
 Ein Entwickler muß ein check-out-Kommando absetzen, um ein Objekt
verändern zu können
 Dieses wird dann in den privaten Speicherbereich kopiert, ist aber noch
unter dem ursprünglichen Namen und Pfad ansprechbar
 Check-In
 Das check-in-Kommando erzeugt eine neue Objektversion im VOB und
löscht die private Kopie
 Locking: Nur derjenige Entwickler, der das check-out-Kommando
abgesetzt hat, darf die neue Objektversion auch wieder einchecken
 Variante: „unreserved check-out“:
 „first check-in wins“; alle anderen müssen mergen
© 2000-2009 Dr. G. Kniesel
Vorlesung „Softwaretechnologie“ (SWT)
Exkurs „ClearCase“, Seite 13
ROOTS
ClearCase Views
src
 Einfacher Weg, viele
Aufgaben zu
managen
 Erlaubt
E l bt d
dynamisches
i h
foo.h
 Schnelles und
ffoo.c
einfaches Wechseln
zwischen
verschiedenen
Aufgaben
u gabe
Teilen der Arbeit
 Kontrolle von
öffentlichen und
privaten Tätigkeiten
src
foo.h
src
foo.c
foo.h
ClearCase Views: Private Storage
View
 Lokale Kopien ermöglichen
das Arbeiten ohne Netzzugriff
 Synchronisation mit der
Datenbank erfolgt
automatisch
 Merging erfolgt automatisch
ClearCase: Verteile Entwicklung
 Paralleles Entwickeln mit
geographisch verteilten ProjektTeams
 Automatische Updates und
Kopien der VOBs
 mit oder ohne Netzzugriff
 Nur ein Team hat "Mastership“
pro branch
© 2000-2009 Dr. G. Kniesel
Vorlesung „Softwaretechnologie“ (SWT)
Exkurs „ClearCase“, Seite 16
ROOTS
ClearCase® Workspace Management: Multi Site Parallel
Development
foo.c
foo c
foo.c
\america
0
1
2
3
1
2
3
\europe
\america
0
0
1
1
2
2
3
1
2
3
\europe
0
1
2
SCM: Das Fundament des
Entwicklungsprozesses
Analysis
Entwurf
Implementierung
Test
Wartung
Software Configuration Management
V i Control
Version
C
l
B ild Management
Build
M
Workspace Management
Process Control
© 2000-2009 Dr. G. Kniesel
Vorlesung „Softwaretechnologie“ (SWT)
Exkurs „ClearCase“, Seite 18
ROOTS
Versionskontrolle: Branching (1)
 „Branching Graph Model“
arc c
arc.c
 Darstellung der wichtigsten
Entwicklungslinien und Change
Sets
 symbolische Namen zum besseren
Verständnis und einfacheren
Referenzieren
 jeder Zweig (Branch) hat
zusätzliche administrative
Annotationen
1
V1
new_guii
 symbolischer
b li h N
Name
 Verweis auf Abspaltungspunkt
1
2
V1_maintenance
3
V1.1
2
7
13
V1.2
1
bug=239
bug
239
2
bug=248
3
bug=267
4
bug=268
5
bug=301
V2 18
 Kommentare
 ...
© 2000-2009 Dr. G. Kniesel
Vorlesung „Softwaretechnologie“ (SWT)
Exkurs „ClearCase“, Seite 19
ROOTS
Versionskontrolle: Branching (2)
 Uneingeschränktes branching
wird
d unterstützt
u te stüt t
 Automatisches branching, wann
Release 1.0
immer es nötig ist
0
 Jedes Mitglied hat einen
\d l
\development
isolierten Arbeitsbereich
 Verschiedene Arbeitsbereiche
für verschiedene Aktivitäten
0
1
1
2
\b fi
\bugfix
0
1
 Erlaubt parallele und
durchgängige
g g g Entwicklung
g
© 2000-2009 Dr. G. Kniesel
Vorlesung „Softwaretechnologie“ (SWT)
Exkurs „ClearCase“, Seite 20
ROOTS
Versionskontrolle: Merging (1)
 Isolierte Arbeitsbereiche werden
integriert
teg e t
 Fördert und schafft Transparenz
Release 1.0
0
 Ein Merge Manager unterstützt
automatisches Merging und hilft
beim Auflösen eventueller
Konflikte
\d l
\development
0
 Merging ist in alle Richtungen
möglich
1
1
2
3
\b fi
\bugfix
0
1
4
© 2000-2009 Dr. G. Kniesel
Vorlesung „Softwaretechnologie“ (SWT)
Exkurs „ClearCase“, Seite 21
ROOTS
Versionskontrolle: Merging (2)
Basisversion
 Problemskizze
...
x=0
...
 merging
i erfolgt
f l t automatisch,
t
ti h
falls gemeinsamer Vorfahre
der zwei Dateien bekannt ist
Version A
...
x=0
...
 Idee
 Änderungen übernehmen
...
x=1
...
Version B
...
???
...
 Experimentelle Resultate
 In ca.
ca 90% der Fälle konnte das Zusammenführen ohne Rückfragen
durchgeführt werden.
 Ca. 1% der automatischen Zusammenführungen war fehlerhaft, was meist
beim Übersetzen entdeckt wurde (Syntaxfehler)
© 2000-2009 Dr. G. Kniesel
Vorlesung „Softwaretechnologie“ (SWT)
Exkurs „ClearCase“, Seite 22
ROOTS
ClearCase® Versionskontrolle: Branching
& Merging
 Isoliert riskante Entwicklungen und Tests
 Stellt sicher, dass einmal behobene Fehler
für immer verschwinden
Release 1.0
0
 Merge-Utility findet noch nicht gemergte
Dateien
\development
 Änderungen
g an Releases werden
transparent
 Releases
auff verschiedenen
Plattformen
R l
hi d
Pl
ttf
werden ermöglicht
 Integrationsaufwand wird drastisch reduziert
0
1
1
2
3
4
\bugfix
0
1
Versionierung von Ordnern
/usr/src/proj
/usr/src/proj
gui_src
gui
gui_doc
schedule
schedule
src
arc.c
zbuf.c
doc
p
plan.doc
arc c
arc.c
zbuf c
zbuf.c
plan doc
plan.doc
 Obige Änderung entspricht einer neuen Version des Ordners
/usr/src/proj/
© 2000-2009 Dr. G. Kniesel
Vorlesung „Softwaretechnologie“ (SWT)
Exkurs „ClearCase“, Seite 24
ROOTS
Versionskontrolle (3):
Erweiterungsmöglichkeiten
 Labels
(hyperlink)
arc c
arc.c
 symbolische
b li h N
Namen
design_for
1
 Attribute
2
 zusätzliche Anmerkungen
 Hyperlinks
RLS1
(label)
arc doc
arc.doc
1
change_req=218
(attribute)
3
2
RLS1
3
RLS2
 Beziehungen
 Trigger
7
 ECA-Regeln
 Change Sets
 Annotationen (auf Code-Ebene)
 Namespaces
a espaces
 ...
© 2000-2009 Dr. G. Kniesel
Vorlesung „Softwaretechnologie“ (SWT)
Exkurs „ClearCase“, Seite 25
ROOTS
ClearCase Baselining
h
c
rc
minicalc.dsw
minicalc.h
minicalc.cpp
minicalc.rc
0
0
0
0
Release 1
1
Release 1
1
2
2
Release 1
Release 1
1
1
Release 2
Release 2
2
Release 2
3
4
3
Release 2
Jede
J
d Version
V i innerhalb
i
h lb des
d Release
R l
kann
k
ein
i
globales Label (z.B. "Release 1") erhalten
ClearCase® Übersicht
Version Control
Build Management
Workspace
p
Management
g
Process Control
© 2000-2009 Dr. G. Kniesel
Vorlesung „Softwaretechnologie“ (SWT)
Exkurs „ClearCase“, Seite 28
ROOTS
Build Management: Mit herkömmlichen
Werkzeugen (make)
 Keine automatisierte Abhängigkeitsanalyse
 Abhängigkeiten
Abhä i k it werden
d vom B
Benutzer
t
manuellll b
beschrieben
h i b ((makefile)
k fil )
 Das ist aber in einer sich dynamisch ändernden Umgebung sehr aufwendig
und fehleranfällig
 Kein „Bill of materials“
 unklar ob zwei abgeleitete Produkte gleichen Namens (foo
(foo.o)
o) wirklich
gleich sind, da nicht klar ist, ob sie auch aus den gleichen „Zutaten“ und
nach der gleichen „Rezeptur“ erstellt wurden
 Kein „Binary sharing“
 Das "normale" Make weiß nichts darüber,, dass ein Kollege
g evtl. ein
aufwendig zu erstellendes abgeleitetes Objekt schon erzeugt hat
© 2000-2009 Dr. G. Kniesel
Vorlesung „Softwaretechnologie“ (SWT)
Exkurs „ClearCase“, Seite 29
ROOTS
Build Management: Mit ClearCase
 Verwaltung von Informationen zum reproduzierbaren Erstellen von
abgeleiteten
abge
e tete Obje
Objekten
te
 Technische Grundlage
 Durch das VFS ist es möglich, die I/O-Zugriffe vom Compiler oder anderen
W k
Werkzeugen
auff alle
ll beteiligten
b t ili t Obj
Objekte
kt erfassen
f
und
d protokollieren
t k lli
zu
lassen.
 clearmake erledigt diese Aufgabe
 Protokollierung der benötigte Daten (Auditing)  Bestandsliste (bill-of-
materials)
 Korrekte Versionen aller Quell
Quell-Dateien
Dateien und anderer beteiligter Objekte
 Namen und Versionen der verwendeten Werkzeuge
 benutzte Parametereinstellungen
 Resultierende nützliche Eigenschaften
 Abgeleitete Objekte können von verschiedenen Benutzern genutzt werden
(binary sharing)
 Nur die notwendigsten Operationen zum Erstellen eines abgeleiteten
Objekts müssen durchgeführt werden (minimal rebuilding)
Build Management: Lösung mit ClearCase
clearmake
audit on
invoke build script
audit off
additional
information
f
/bin/cc -g parse.c
view
Config Record
File System I/O Audit
parse.c@@/main/17
parse.h@@/main/7
lex
h@@/main/93
lex.h@@/main/93
parse.o@@12-Jul
---------------HP/UX 9.0.3
/bin/cc -g parse.c
Bill-of-material = „Stückliste“
der „Zutaten“ für die Herstellung
dieses abgeleiteten Objektes.
VOB repository
ClearCase® Build und Release
Management
 Build Maintenance
 Automatisches
A t
ti h Erkennen
Ek
von Abhängigkeiten
Abhä i k it
 Stellt sicher, dass ein Build die richtigen Versionen einzelner Elemente
beinhaltet
 Konfigurationsprofile bestimmen exakt jede Version der benutzten
Elemente
© 2000-2009 Dr. G. Kniesel
Vorlesung „Softwaretechnologie“ (SWT)
Exkurs „ClearCase“, Seite 32
ROOTS
ClearCase® Build und Release
Management
bar.c
 Build Auditing (Protokollierung)
 Reproduzierbarkeit von builds durch
Anfertigen von “Stücklisten”
Target foo.o built on host ‘falcon’ by arthur
Reference Time 4-June-2001, 1:30:42
View was falcon:/home/falcon/arthur/myview
/usr/vob/src@@/main/12
/usr/vob/src/foo.c@@/main/bugfix/4
/
/usr/vob/src/foo.h@@/main/17
/
/
/
/
/
/usr/vob/src/foo.h@@main/9
Build Script:
cc -g -o foo foo.c
New Build
project
bin
foo.o
src
foo c
foo.c
bar.c
V
I
E
W
foo.o
foo.c
Private Storage
User ‘arthur’
foo.c
ClearCase® Build und Release
bar.c
bar c
Management
foo.o
foo o
foo.c
foo c
 Build Avoidance (Vermeidung)
 Entwickler können “abgeleitete Objekte” teilen
Target foo.o built on host ‘falcon’ by ford
Reference Time 5-June-2001
5-June-2001, 9:14:42
View was falcon:/home/falcon/ford/myview
/usr/vob/src@@/main/12
/usr/vob/src/foo.c@@/main/bugfix/4
/usr/vob/src/foo h@@/main/17
/usr/vob/src/foo.h@@/main/17
/usr/vob/src/foo.h@@main/9
Build Script:
cc -g -o foo foo.c
New Build
project
bin
foo o
foo.o
src
foo.c
bar c
bar.c
V
I
E
W
foo.o
foo.c
Private Storage
User ‘ford’
Nicht
erforderlich
foo.c neu zu
kompilieren
ClearCase® Build And Release
Management
 Build Performance
VOB Server Hosts
 Ermöglicht
E ö li ht parallele
ll l und
d
verteilte builds über das
Netzwerk (UNIX)


HP
DEC
Sun
HP


Sun
SGI
IBM
NT
Teil-Builds können verteilt werden
© 2000-2009 Dr. G. Kniesel
Vorlesung „Softwaretechnologie“ (SWT)
Exkurs „ClearCase“, Seite 35
ROOTS
ClearCase® Build und Release Management:
Zusammenfassung
 Build Maintenance
 Automatisches
A t
ti h Erkennen
Ek
von Abhängigkeiten
Abhä i k it
 Build Auditing
g ((Protokollierung)
g)
 Reproduzierbarkeit von builds durch Anfertigen von “Stücklisten”
 Build Avoidance (Vermeidung)
 Ermöglicht das Teilen von “abgeleiteten Objekten" zwischen Entwicklern
 Build Performance
 Ermöglicht parallele und verteilte builds
© 2000-2009 Dr. G. Kniesel
Vorlesung „Softwaretechnologie“ (SWT)
Exkurs „ClearCase“, Seite 36
ROOTS
ClearCase® Übersicht
Version Control
Build Management
Workspace
p
Management
g
Process Control
© 2000-2009 Dr. G. Kniesel
Vorlesung „Softwaretechnologie“ (SWT)
Exkurs „ClearCase“, Seite 37
ROOTS
Process Control
 Entwicklungsprozeß umfaßt Analyse, Design, Implementierung und
Wartung des Software-Produkts
Software Produkts
 SCM ist nur ein Teil in diesem Prozeß neben
 der Eingrenzung von Problemen,
 der Definition von Maßnahmen,
 dem Erstellen von Zeitplänen,
p
,
 dem (automatischen) Testen,
 dem Messen von Software-Eigenschaften
 und anderen Aufgaben
Aufgaben.
 Geeignete Werkzeuge zur Automatisierung von Entwicklungs-
Prozessen sind
P
i d sog. "W
"Workflow
kfl
Manager„.
M
 Deren grundlegendes Konzept ist Action-Response, d.h. die
Bearbeitung von Teilaufgaben kann andere Teilaufgaben beeinflussen
oder anstoßen.
© 2000-2009 Dr. G. Kniesel
Vorlesung „Softwaretechnologie“ (SWT)
Exkurs „ClearCase“, Seite 38
ROOTS
Die Lösung: Unified Change Management
Akti ität
Aktivitäten
Activity
Activity
Activity
Aktivitäten - werden
definiert um das
Projekt
voranzubringen
Artefakte
Artefakte - Dateien die
während
äh d des
d Projekts
P j kt
angelegt/verändert
werden
© 2000-2009 Dr. G. Kniesel
Vorlesung „Softwaretechnologie“ (SWT)
Exkurs „ClearCase“, Seite 39
ROOTS
Die Lösung: Unified Change Management
Projekt Manager
Projekt erzeugen
Baseline definieren
Richtlinien
festlegen
E t i kl
Entwickler
Integrator
Anmelden am
Projekt
Integration
Arbeiten an
Aktivitäten
B li erzeugen
Baseline
Arbeitsumgebung
aktualisieren
Baselinegüte
vergeben
Aktivitäten
abliefern
© 2000-2009 Dr. G. Kniesel
Vorlesung „Softwaretechnologie“ (SWT)
Exkurs „ClearCase“, Seite 40
ROOTS
UCM: Verbindung zwischen Aktivitäten
und Artefakten
ClearQuest: Aktivitäten
Verwaltung der
Aktivitäten
Request
Priority
Owner
Special Promo
1
Terry
Bug 527
2
Sandy
Add GUI button
2
Kim
Cl
C
A
t f kt
ClearCase:
Artefakte
Ch
Change S
Sett
Special Promo
Verwaltung
V
lt
der
d
Artefakte
© 2000-2009 Dr. G. Kniesel
Vorlesung „Softwaretechnologie“ (SWT)
a html
a.html
V5
c.xml
V3
b.jpg
V8
Exkurs „ClearCase“, Seite 41
ROOTS
ClearCase® Zusammenfassung
Version Control
Full Branching & Labeling
All File System Elements
Directories
Graphical Merge & Compare
Conversion Utilities
Build Management
makefile compatible
Automatic Dependency Mgmt
Build Auditing - Config Records
Parallel, Distributed Building
Binary Sharing
Workspace
W
k
M
Managementt
Rule-based Configurations
Dynamic Evaluation
Transparent Access
Scalable
Fully Distributed
Process C
P
Control
t l
Attributes
Hyperlinks
Pre Event Post
Pre-Event,
Post-Event
Event Triggers
Locks & Permissions
Completely Customizable
© 2000-2009 Dr. G. Kniesel
Vorlesung „Softwaretechnologie“ (SWT)
Exkurs „ClearCase“, Seite 42
ROOTS
ClearCase Summary
ClearCase Pros
ClearCase Cons
 Industrial strength
 Very expensive
 Excellent merge tools
 Heavyweight server and client
 Proven reliability
 Very steep learning curve
 Scales up well
 High administration burden

 Server communication over a
Good GUI on Windows
high latency link is SLOW
 All merges are server based
 You can't merge or diff without
connectivity to the servers
 Merges over high latency links
are SLOW
 You need to do many things
the ClearCase way
 Weak GUI on Unix platforms
© 2000-2009 Dr. G. Kniesel
Vorlesung „Softwaretechnologie“ (SWT)
Exkurs „ClearCase“, Seite 43
ROOTS
Zusammenfassung: SCM De Luxe
 Virtuelles Dateisystem
  Transparenz
T
der
d Datenhaltung
D t h lt
 Regelbasierte Konfiguration des Arbeitsbereiches
  Flexibilität
 Dynamische Regelauswertung
  Aktualität
 Automatisches Merging
  Geringer Integrationsaufwand
 Build Management
  Reproduzierbare „build“-Ergebnisse, Effizienz durch „minimal rebuilding“
g
 ECA-Regeln
  Workflow-Management
 Verteilung, automatische Spielelung, verteiltes Building
  Unterstützung für internationale Unternehmen
© 2000-2009 Dr. G. Kniesel
Vorlesung „Softwaretechnologie“ (SWT)
Exkurs „ClearCase“, Seite 44
ROOTS