1. 1 Multi-level Configuration Management with Fine-grained Logical Units Tien N. Nguyen Electrical and Computer Engineering Department Iowa State University

2. 2 Design and Implementation Class ---------------------------- Function -------------------- ----------------------------------------- ----------------------------------------- ----------------------------------------- ---------------------------------------- ======================== Design/Implementation Design spec 1: ----- ----------------------------------------- Design spec 2: ----- ----------------------------------------- ----------------------------------------- ----------------------------------------- -----------------------------------------

3. 3 File-oriented SCM Class ---------------------------- Function -------------------- ----------------------------------------- ----------------------------------------- ----------------------------------------- ---------------------------------------- ======================== Design/Implementation Design spec 1: ----- ----------------------------------------- Design spec 2: ----- ----------------------------------------- ----------------------------------------- ----------------------------------------- ----------------------------------------- FILES/ DIRECTORIES File-based SCM system  Primary targets of SCM are files/directories. Configuration Management

4. 4 Mismatch between two domains Class, function, statement,… Design/Implementation Configuration Management Files and Directories n Developers work with logical units, but manage versions and configurations of files and directories.

5. 5 Logical and structural problems n SCM systems have little or no knowledge of file contents. Logical structure of a program is not preserved in a SCM repository. n Some SCM systems are based on a line- oriented model of internal changes of files. n Extensive analyses are required to recover structural changes between different versions of a sub-file program unit. => SCM systems should provide fine-grained version control for logical units

6. 6 Existing fine-grained SCM models n Predefined set of versionable units

7. 7 Versioning for composite units n Create versions of a composite unit via structure versioning mechanisms

8. 8 Structure versioning mechanism n Selection of the right versions of atomic units to be included in a version of a composite unit composite unit D a b c

9. 9 Labeling (tagging) approach n Assigning the same labels to unit versions that belong to the same version of a composite. n Makefile and similar ones composite unit D a1 b1 c1

10. 10 Composition versioning approach n Revision Selection Rules (RSRs)

11. 11 Total versioning approach n All levels of hierarchy are versioned.

12. 12 Product versioning approach n A version is global across entire software project

13. 13 Multi-level logical units … … …… project file class method stmt char token

14. 14 Multi-level logical units (2) … … …… project section subsection paragraph sentence char word

15. 15 n All levels of structural hierarchy are important. n For documentation, SCM tools should not impose a predefined set of structural units. u inflexible, inextensible, and fixed u There is no basic set of units that can accommodate all structural levels. u Cost to maintain mapping between versions of logical units and versions of files Analyses

16. 16 n Existing fine-grained version control systems u inflexible, inextensible, and fixed u There is no basic set of units that can accommodate all structural levels. u Cost to maintain mapping between versions of logical units and versions of files Analyses

17. 17 n Combination approach u structure-oriented representation model and u product versioning model n Multiple structural levels are controllable. n SCM handled via one uniform mechanism n Efficient structural differencing tools: neither tree differencing algorithm nor extensive analyses are required Structure-oriented Product versioning model

18. 18 Structure-oriented representation n Each software document is represented by a XML-like document tree. n Each node in a tree has a unique identifier and can be associated with multiple attributes in any data type. n An attribute value u is a location that stores a value of any data type, possibly a reference. u can be either versioned or non-versioned.

19. 19 Example First floor scenario Person is on the 1 st floor … “operator”“children”“parent”“content”“author” n1Intop(“use-case”)[n2,n4]null “John…” n2Intop(“name”)[n3]n1nullUndefined n3textopnulln2“First …”Undefined n4Intop(“cond”)[n5]n1nullUndefined n5Intop(“pre-cond”)[n6]n4nullUndefined n6textopnulln5“Person...”Undefined Attribute table … …

20. 20 Example First floor scenario Person is on the 1 st floor … “operator”“children”“parent”“content”“author” n1Intop(“use-case”)[n2,n4]null “John…” n2Intop(“name”)[n3]n1nullUndefined n3textopnulln2“First …”Undefined n4Intop(“cond”)[n5]n1nullUndefined n5Intop(“pre-cond”)[n6]n4nullUndefined n6textopnulln5“Person...”Undefined Attribute table version … …

21. 21 Benefits n Allow the modeling of any structural levels in a software document n No hard-code or predefined set of versionable units n Structural levels are controllable u New XML element can be added. u Also via the use of Document Type Definition (DTD) and XML Schema => accommodate any document type

22. 22 Tree-structured discrete time Project V1.0 Project V2.0 Project V3.0 Project V3.1 Project V3.2 n A version is a point in the project’s lifetime. Product versioning model

23. 23 Tree-structured discrete time Project V1.0 Project V2.0 Project V3.0 Project V3.1 Project V3.2 n One global version space across entire project Product versioning model (2)

24. 24 n Users select a current version to work on. Tree-structured discrete time Project V1.0 current => Project V2.0 Project V3.0 Project V3.1 Project V3.2 Unnamed, temporary version Editing and versions

25. 25 Structure versioning scheme Class() ------------------------ Function () -------------- ----------------------------------------- ----------------------------------------- ----------------------------------------- ---------------------------------------- ======================== Structured editors Attributed trees

26. 26 1 2 3 4 5 1 2 3 Version v1 Version v2 (content is modified) ContentChildrenParent n1 “”[n2,n3]null n2“”[n4,n5]n1 n3“”nulln1 n4“”nulln2 n5“old”nulln2 ContentChildrenParent n1“”[n2,n3]null n2“”[n5]n1 n3“”nulln1 n4“”null n5“new”nulln2 5 Fine-grained structure versioning

27. 27 Benefits of this scheme n Common structure shared among versions n Nodes can participate in many trees. n One version mechanism for all information n Fine-grained version control for all structural levels in source code and documentation

28. 28 Configuration Management n A software system is more than a simple collection of documents. n How to maintain consistent configurations among document trees? n SCM tasks are handled by Molhado, u An object-oriented SCM infrastructure [Nguyen et al, ICSE 2005] u Provide SCM and transaction support, operation model, collaborative support, etc.

29. 29 n The structure-oriented product versioning model was integrated into the Software Concordance (SC) environment. n SC is a complete environment u Supporting structured editing for Java, XML and HTML documentation, SVG graphics, UML diagrams, u Supporting program analysis, and u Supporting hyperlinks. Implementation

30. 30 Select the current working version

31. 31 Structured editor

32. 32 Fine-grained version control

33. 33 Fine-grained version control (2)

34. 34 Fine-grained version control (3)

35. 35 Project structure comparison

36. 36 Java program comparison

37. 37 UML diagrams

38. 38 Version control for SVG graphics

39. 39 n Existing fine-grained SCM systems u Manage basic versionable units as files, then create versions of larger units via structure versioning. u Inflexible, inextensible, fixed, and file-based n Combination approach of product versioning and structure-oriented representation u Multiple structural levels u SCM handled via one uniform mechanism u Efficient structural differencing tools Conclusions