Browse Prior Art Database

INTELLIGENT MERGE OF SOFTWARE COMPONENTS

IP.com Disclosure Number: IPCOM000008408D
Original Publication Date: 1997-Dec-01
Included in the Prior Art Database: 2002-Jun-12
Document File: 3 page(s) / 134K

Publishing Venue

Motorola

Related People

Bill Foster: AUTHOR

Abstract

Medium to large software development projects typically divide the project into features or services and then group a set of these features into what will become a single software release. Subsequent releases consist of additional features and mainte- nance of existing features. Despite admirable goals to the contrary, when starting with a fresh sheet of paper design, the functionality in a single feature often overlaps with that of another feature. Furthermore the functionality of any given feature is frequently spread across more than one software module. This feature interdependency gets infinitely more complicated when maintaining a legacy soft- ware project.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 50% of the total text.

Page 1 of 3

0 M

MOTOROLA Technical Developments

INTELLIGENT MERGE OF SOFTWARE COMPONENTS

by Bill Foster

BACKGROUND

  Medium to large software development projects typically divide the project into features or services and then group a set of these features into what will become a single software release. Subsequent releases consist of additional features and mainte- nance of existing features. Despite admirable goals to the contrary, when starting with a fresh sheet of paper design, the functionality in a single feature often overlaps with that of another feature. Furthermore the functionality of any given feature is frequently spread across more than one software module. This feature interdependency gets infinitely more complicated when maintaining a legacy soft- ware project.

Each software module in a project is maintained

on a mainline for that individual module. To insure the integrity of a module, a branch from a mainline is created, allowing the mainline to continue undis- turbed and to remain available for interim releases while the feature is being developed.

  Parallel feature development requires that mul- tiple developers have access to the same modules on a project. When two or more developers require the same module, multiple branches are created from the modules mainline.

  As one or more features nears completion the modules involved must be merged back into their corresponding mainlines in a controlled and orderly fashion.

  Software Project Management Plans continually struggle with this feature interaction and interde- pendency during the development phase leading up to a software release. Three conflicting goals arise at this point.

I) Keep the mainlines as pure as possible so that an interim release, for maintenance or for a repriori- tized feature set release, can be created.

2) Bring all the new software together as soon as possible so that ongoing testing will uncover any interdependency issues,

3) Only release software from the modules main- line so that there is no need to maintain Special Products or customer specific releases.

PROBLEM

  Deciding when a software branch, containing numerous modules, is ready for merging back into a mainline is a manual process requiring significant labor to determine when all the modules are ready. Modules may accidentally be merged before they are fully debugged or a new version of a module may be left out.

  Version control programs and merge utilities exist which can merge versions of a single module, however they cannot determine when each of the modules are actually ready for merging.

\o Motorola. 1°C 19'27 43 December 1997

[This page contains 15 pictures or other non-text objects]

Page 2 of 3

0 M

MOTOROLA Technical Developments

Elite. cpp module

'Toronto" branch

Criteria specifies when the branches are ready to be merged.

Fig. 1 Merging Software Components

AND S...