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

1

Multi-level Configuration Management with Fine-grained Logical Units

Tien N. NguyenElectrical and Computer Engineering Department

Iowa State University

2

Design and Implementation

Class----------------------------

Function--------------------

-------------------------------------------------------------------------------------------------------------------------------------------------------------------========================

Design/Implementation

Design spec 1:------------------------------------

----------Design spec 2:------------------------------------

-------------------------------------------------------------------------------------------------------------------------------------

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

Mismatch between two domainsClass,

function, statement,…

Design/Implementation Configuration Management

Files and Directories

Developers work with logical units, but manage versions and configurations of files and directories.

5

Logical and structural problems SCM systems have little or no knowledge of

file contents. Logical structure of a program is not preserved in a SCM repository.

Some SCM systems are based on a line-oriented model of internal changes of files.

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

Existing fine-grained SCM models

Predefined set of versionable units

7

Versioning for composite units

Create versions of a composite unit via structure versioning mechanisms

8

Structure versioning mechanism

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

Labeling (tagging) approach

Assigning the same labels to unit versions that belong to the same version of a composite.

Makefile and similar ones

composite unit D

a1

b1 c1

10

Composition versioning approach

Revision Selection Rules (RSRs)

11

Total versioning approach

All levels of hierarchy are versioned.

12

Product versioning approach

A version is global across entire software project

13

Multi-level logical units

…… … …

projectfile

classmethod

stmt

char

token

14

Multi-level logical units (2)

…… … …

projectsection

subsectionparagraph

sentence

char

word

15

All levels of structural hierarchy are important.

For documentation, SCM tools should not impose a predefined set of structural units. inflexible, inextensible, and fixed There is no basic set of units that can

accommodate all structural levels. Cost to maintain mapping between versions

of logical units and versions of files

Analyses

16

Existing fine-grained version control systems inflexible, inextensible, and fixed There is no basic set of units that can

accommodate all structural levels. Cost to maintain mapping between versions

of logical units and versions of files

Analyses

17

Combination approach structure-oriented representation model and product versioning model

Multiple structural levels are controllable. SCM handled via one uniform mechanism Efficient structural differencing tools:

neither tree differencing algorithm nor extensive analyses are required

Structure-oriented Product versioning model

18

Structure-oriented representation Each software document is represented by a

XML-like document tree. Each node in a tree has a unique identifier

and can be associated with multiple attributes in any data type.

An attribute value is a location that stores a value of any data

type, possibly a reference. can be either versioned or non-versioned.

19

Example <use-case author =“John Boyland” no = 654>

<name> First floor scenario </name>

<cond>

<pre-cond> Person is on the 1st floor </pre-cond>…

“operator” “children” “parent” “content” “author”

n1 Intop(“use-case”) [n2,n4] null null “John…”

n2 Intop(“name”) [n3] n1 null Undefined

n3 textop null n2 “First …” Undefined

n4 Intop(“cond”) [n5] n1 null Undefined

n5 Intop(“pre-cond”) [n6] n4 null Undefined

n6 textop null n5 “Person...” Undefined

Attribute table…

…

20

Example <use-case author =“John Boyland” no = 654>

<name> First floor scenario </name>

<cond>

<pre-cond> Person is on the 1st floor </pre-cond>…

“operator” “children” “parent” “content” “author”

n1 Intop(“use-case”) [n2,n4] null null “John…”

n2 Intop(“name”) [n3] n1 null Undefined

n3 textop null n2 “First …” Undefined

n4 Intop(“cond”) [n5] n1 null Undefined

n5 Intop(“pre-cond”) [n6] n4 null Undefined

n6 textop null n5 “Person...” Undefined

Attribute table

version

…

…

21

Benefits Allow the modeling of any structural levels

in a software document No hard-code or predefined set of

versionable units Structural levels are controllable

New XML element can be added. Also via the use of Document Type

Definition (DTD) and XML Schema => accommodate any document type

22

Tree-structured discrete timeProject V1.0

Project V2.0

Project V3.0

Project V3.1 Project V3.2

A version is a point in the project’s lifetime.

Product versioning model

23

Tree-structured discrete timeProject V1.0

Project V2.0

Project V3.0

Project V3.1 Project V3.2

One global version space across entire project

Product versioning model (2)

24

Users select a current version to work on.

Tree-structured discrete timeProject V1.0

current => Project V2.0

Project V3.0

Project V3.1 Project V3.2

Unnamed, temporary version

Editing and versions

25

Structure versioning scheme

Class()------------------------

Function ()-------------------------------------

--------------------------------------------------------------------------------------------------------------------------------------------========================

Structured editors

Attributed trees

26

1

2 3

4 5

1

2 3

Version v1 Version v2

(content is modified)

Content Children Parent

n1 “” [n2,n3] null

n2 “” [n4,n5] n1

n3 “” null n1

n4 “” null n2

n5 “old” null n2

Content Children Parent

n1 “” [n2,n3] null

n2 “” [n5] n1

n3 “” null n1

n4 “” null null

n5 “new” null n2

5

Fine-grained structure versioning

27

Benefits of this scheme Common structure shared among versions Nodes can participate in many trees. One version mechanism for all information Fine-grained version control for all

structural levels in source code and documentation

28

Configuration Management A software system is more than a simple

collection of documents. How to maintain consistent configurations

among document trees? SCM tasks are handled by Molhado,

An object-oriented SCM infrastructure [Nguyen et al, ICSE 2005]

Provide SCM and transaction support, operation model, collaborative support, etc.

29

The structure-oriented product versioning model was integrated into the Software Concordance (SC) environment.

SC is a complete environment Supporting structured editing for Java, XML

and HTML documentation, SVG graphics, UML diagrams,

Supporting program analysis, and Supporting hyperlinks.

Implementation

30

Select the current working version

31

Structured editor

32

Fine-grained version control

33

Fine-grained version control (2)

34

Fine-grained version control (3)

35

Project structure comparison

36

Java program comparison

37

UML diagrams

38

Version control for SVG graphics

39

Existing fine-grained SCM systems Manage basic versionable units as files, then create

versions of larger units via structure versioning. Inflexible, inextensible, fixed, and file-based

Combination approach of product versioning and structure-oriented representation Multiple structural levels SCM handled via one uniform mechanism Efficient structural differencing tools

Conclusions