Informatics 211: Configuration Management & Coordination

1. Informatics 211:Configuration Management & Coordination André van der HoekUniversity of California, IrvineDonald Bren School of Information and Computer SciencesDepartment of Informaticsandre@ics.uci.edu (c) 2007 University of California, Irvine – André van der Hoek

2. A Simplified Development Scenario Pete’s workspace Ellen’s workspace CM repository Pete Ellen (c) 2007 University of California, Irvine – André van der Hoek

3. Direct Conflicts Pete’s workspace Ellen’s workspace CM repository changes changes Pete Ellen Conflicting changes to the same artifact (c) 2007 University of California, Irvine – André van der Hoek

4. Indirect Conflicts Pete’s workspace Ellen’s workspace CM repository changes changes Pete Ellen Conflicting changes to different artifacts (c) 2007 University of California, Irvine – André van der Hoek

5. Configuration Management • “Configuration management (CM) is a discipline whose goal is to control changes to large software through the functions of: component identification, change tracking, version selection and baselining, software manufacture, and managing simultaneous updates (team work).” Walter Tichy, SCM-1, 1988 (c) 2007 University of California, Irvine – André van der Hoek

6. CM Spectrum of Functionality • Components • Versions • Configurations • Baselines • Project contexts • Structure • System model • Interfaces • Consistency • Selection • Construction • Building • Snapshots • Regeneration • Optimization • Controlling • Access control • Change requests • Bug tracking • Partitioning • Accounting • Statistics • Status • Reports • Auditing • History • Traceability • Logging • Process • Lifecycle support • Task mgmt. • Communication • Documentation • Team • Workspaces • Merging • Families Susan Dart, SCM-3, 1991 (c) 2007 University of California, Irvine – André van der Hoek

7. Three Generations of CM Systems Continuus DaSC ClearCase Perforce NUCM Asgard CCC/Harvest TRUEchange Proteus ICE Serena Vesta Endevor Functionality NSE PVCS EPOS DSEE Source Integrity Adele VOODOO CVS RCS Odin ShapeTools Sablime Jasmine Research Development SCCS Time (c) 2007 University of California, Irvine – André van der Hoek

8. First Generation • Focused on: • archiving individual elements • strictly avoiding conflicts • Characterized by: • simple, separate tools • development orientation • Canonical examples • SCCS • RCS • Make (c) 2007 University of California, Irvine – André van der Hoek

9. First Generation: Version Graphs 1.0 1.1 Author = “André v/d Hoek”Date = 01/12/2001Time = 7:52amComment = “Trying new stuff”Lock = “andre@ics.uci.edu” 1.2 1.2.1.0 2.0 1.2.1.1 2.1 (c) 2007 University of California, Irvine – André van der Hoek

10. First Generation • Components • Versions • Configurations • Baselines • Project contexts • Structure • System model • Interfaces • Consistency • Selection • Construction • Building • Snapshots • Regeneration • Optimization • Controlling • Access control • Change requests • Bug tracking • Partitioning • Accounting • Statistics • Status • Reports • Auditing • History • Traceability • Logging • Process • Lifecycle support • Task mgmt. • Communication • Documentation • Team • Workspaces • Merging • Families (c) 2007 University of California, Irvine – André van der Hoek

11. Second Generation • Focused on: • archiving compound elements • different version models • Characterized by: • integrated versioning & build tools • development orientation • Canonical examples: • CVS • Subversion • PVCS • SourceSafe (c) 2007 University of California, Irvine – André van der Hoek

12. Four Canonical Version Models • State-based extensional • version tree • State-based intensional • conditional compilation • Change-based extensional • change packages • Change-based intensional • change sets (c) 2007 University of California, Irvine – André van der Hoek

13. Conditional Compilation …#ifdef UNIX #include <stdio.h>#endif#ifdef GRAPHICS #include <graphics.h> #ifdef SMARTGRAPHICS #include <smart.> #endif#endif… (c) 2007 University of California, Irvine – André van der Hoek

14. Change Packages 1.0 1.0 1.0 1.0 2.0 1.1 1.1 1.1 2.1 1.2 1.2.1.0 1.2 2.2 2.0 1.2.1.1 1.3 2.0.1.0 1.2 2.3 2.1 2.0 (c) 2007 University of California, Irvine – André van der Hoek

15. Change Sets AVAILABLECHANGESETS SYSTEMSELECTION Bug fix #17 Feature addition#104 Bug fix #21 Feature addition#103 Bug fix #8 Bug fix #6 Bug fix #16 Baseline Bug fix #16 (c) 2007 University of California, Irvine – André van der Hoek

16. Second Generation • Components • Versions • Configurations • Baselines • Project contexts • Structure • System model • Interfaces • Consistency • Selection • Construction • Building • Snapshots • Regeneration • Optimization • Controlling • Access control • Change requests • Bug tracking • Partitioning • Accounting • Statistics • Status • Reports • Auditing • History • Traceability • Logging • Process • Lifecycle support • Task mgmt. • Communication • Documentation • Team • Workspaces • Merging • Families (c) 2007 University of California, Irvine – André van der Hoek

17. Third Generation • Focused on: • providing process support • being all-encompassing • Characterized by: • large, complex tools • management orientation • Canonical examples: • ClearCase together with ClearGuide • CM/Synergy (c) 2007 University of California, Irvine – André van der Hoek

18. Third Generation • Components • Versions • Configurations • Baselines • Project contexts • Structure • System model • Interfaces • Consistency • Selection • Construction • Building • Snapshots • Regeneration • Optimization • Controlling • Access control • Change requests • Bug tracking • Partitioning • Accounting • Statistics • Status • Reports • Auditing • History • Traceability • Logging • Process • Lifecycle support • Task mgmt. • Communication • Documentation • Team • Workspaces • Merging • Families (c) 2007 University of California, Irvine – André van der Hoek

19. A Fourth Generation ? (c) 2007 University of California, Irvine – André van der Hoek

20. No… • CM core functionality is stable with well-understood choices • CM tool enhancement seems to be limited to feature creep, not fundamental new approaches • SCM workshop series has ended • Only a few pure CM papers are being published as of late (c) 2007 University of California, Irvine – André van der Hoek

21. Maybe… • CM functionality is now appearing in domains other than source code management • web content management • product data management • web services and components • software deployment • product line architectures • … • Mining software repositories • no better repository than the CM repository • Still some problems left • indirect conflicts • concern management • Coordination (c) 2007 University of California, Irvine – André van der Hoek

22. Product Line Architectures: The Problem • “A software product line (SPL) is a strategic software-based asset that explicitly recognizes, optimizes, and manages variability towards current and future feature changes.” [van der Hoek] • But how to manage this asset? (c) 2007 University of California, Irvine – André van der Hoek

23. Classic Versioning for Product Lines (c) 2007 University of California, Irvine – André van der Hoek

24. Creating the Baseline (c) 2007 University of California, Irvine – André van der Hoek

25. Creating the Baseline (c) 2007 University of California, Irvine – André van der Hoek

26. Creating the Baseline (c) 2007 University of California, Irvine – André van der Hoek

27. Creating the Baseline (c) 2007 University of California, Irvine – André van der Hoek

28. Creating the Baseline (c) 2007 University of California, Irvine – André van der Hoek

29. Creating the Baseline (c) 2007 University of California, Irvine – André van der Hoek

30. Creating the Baseline (c) 2007 University of California, Irvine – André van der Hoek

31. Viewing the Baseline (c) 2007 University of California, Irvine – André van der Hoek

32. Excluding the Baseline (c) 2007 University of California, Irvine – André van der Hoek

33. Including the Baseline (c) 2007 University of California, Irvine – André van der Hoek

34. Creating the Record Support (c) 2007 University of California, Irvine – André van der Hoek

35. Creating the Record Support (c) 2007 University of California, Irvine – André van der Hoek

36. Viewing the Record Support (c) 2007 University of California, Irvine – André van der Hoek

37. Removing Old Elements (c) 2007 University of California, Irvine – André van der Hoek

38. Removing Old Elements (c) 2007 University of California, Irvine – André van der Hoek

39. Removing Old Elements (c) 2007 University of California, Irvine – André van der Hoek

40. Removing Old Elements (c) 2007 University of California, Irvine – André van der Hoek

41. Adding New Elements (c) 2007 University of California, Irvine – André van der Hoek

42. Viewing the CD Writer (c) 2007 University of California, Irvine – André van der Hoek

43. Trial Product (c) 2007 University of California, Irvine – André van der Hoek

44. Pro Product (c) 2007 University of California, Irvine – André van der Hoek

45. All Music Player Change Sets (c) 2007 University of California, Irvine – André van der Hoek

46. Visualizing Relationships (c) 2007 University of California, Irvine – André van der Hoek

47. Example Relationships (c) 2007 University of California, Irvine – André van der Hoek

48. Product Compositions (c) 2007 University of California, Irvine – André van der Hoek

49. Additional Relationships (c) 2007 University of California, Irvine – André van der Hoek

50. Violated Relationships (c) 2007 University of California, Irvine – André van der Hoek