3.4 Trends

---

SCM as a discipline has achieved a level of maturity that permits its implementation in many variants. There are over 100 SCM tools currently available on the market (see Chapter 11). In addition to these stand-alone tools, many other tools have built-in SCM functionality. SCM tools are sometimes seen as too complex, too expensive, and insufficiently flexible, which results in development organizations preferring to buy or to use free SCM tools. This was not the case in the 1980s, when most of the larger organizations developed their own SCM tools. In most cases, the companies use only basic SCM functionality (i.e., versioning and baselines), while additional functionality, such as change and process management is not used. The most important requirements from industry are not sophisticated functions, but simplicity and interoperability with other tools.

During the entire SCM evolution period, SCM researchers collaborated closely with industry and have been involved in product development. Leading SCM researchers have attended software configuration management symposia in 1988 [24], 1999 [25], and 2001 [26]. These symposia have been characterized by close cooperation between researchers and SCM tool suppliers. Even SCM customers, both large and small companies, have participated and an “industrial experience” session is a normal item on the agenda. One conclusion from discussions at the most recent SCM symposium was that many of the research problems of the 1990s had been solved and the solutions implemented by the vendors. It is to be expected that new problems will be encountered in the next decade, and for this reason the SCM-10 symposium was much more research oriented.

Trends in certain areas currently emphasized by researchers and suppliers are discussed next.

3.4.1 Versioning models

The main stream of solutions today is based on the version mechanism described in Section 3.2.1, storing all versions in a repository. A trend in versioning models is to distinguish different levels of version. The main difference between two versions remains the principal question. Is it the number of different lines or different bytes, or is the difference managed on a higher, semantic, level (e.g., differences of properties of entities), or a functional change introduced in the system, or something else?

The use of change sets—logical changes introduced into the system—is one higher level of change management. The management of changes on this level gives a more distinct separation of the abstract, functional change from its implementation. This, however, can result in an enormous number of versions of configurations, many never existing before and thus never tested. In time it was realized that classical versioning and change-set versioning are complementary, and many SCM tools now use them both.

Another level on which differences can be managed is the semantic level. The logical differences between two items can be recognized on the semantic level. The demand to view differences on this level has increased with the complexity of software entities that cannot be mapped to files or to lines of files. Examples of such are objects in object-oriented programming, tables in a relational database, CAD models, and different type of documents. To recognize these types of differences, SCM tools must understand the semantics of the objects. As these semantics are not standardized, an SCM tool that will understand them all is an impossibility. Another possibility would be to formally specify the common, standardized version management of standard infrastructures and semantics of entities. In that perspective, XML appears promising, as it is flexible and powerful enough to be able to specify different formats that can be used by different tools. As yet, however, except in Web-distributed authoring and versioning (WebDAV) (see Section 3.4.4.2), XML has not been applied to any extent in SCM.

3.4.2 Workspace management

Workspace management is related to the what happens with a file when it is checked out from the repository to a workspace. The simpler tools leave this control to the user; the more advanced tools keep the workspace under their control. For example, ClearCase [11] can find configurations already built in workspaces and in that way speed up the build ordered in another workspace. In the research prototype COOP/Orm, the clients, instead of saving to a local workspace, continuously checkpoint changes to the server to provide developers working on the same document more complete knowledge of activities in the project [27, 28].

In all current solutions, the workspace is mapped to the file system, as the modules are usually implemented as files. However, there is a trend to require management of other types of items also, raising the question of how to manage workspaces for entities different from files (e.g., entities in development environments or databases).

3.4.3 Distributed CM

Distributed SCM has grown in importance with the tremendous increase in the development and use of software and with the globalization of software development and software marketing. Specialization and outsourcing have also influenced the development process. Finally, the Internet and World Wide Web (WWW) have dramatically improved the communication possibilities available to companies using distributed development. The requirements of distributed development are different from those of local development. An increasing number of SCM tool vendors provide support for distributed CM, and this has been a topic of research during recent years.

There are different aspects of distributed SCM. Managing the sourcecode level is an extension of the local management. There are several excellent examples of successful management in the open source domain, including Linux, KDE, and Mozilla (Netscape 7). Many of them use simple SCM tools such as concurrent versions system (CVS). In most of these cases, the central repository accessible via the Internet contains all of the relevant data in one place. Different SCM tools offer support for a more complex management in which repositories are distributed over the networks.

A detailed analysis of SCM and trends in distributed development, as well as use cases from Swedish industry, can be found in [15].

3.4.4 SCM and the Web

With the WWW explosion, the number of files to be managed has increased dramatically, and the lifetime of documents or document versions

has decreased correspondingly. A new challenge for SCM appears—how is this enormous volume of items to be managed? A similar question related to dependency management arises—how is the unlimited number of hyperlinks that are being changed literally every second to be managed? Further, how can SCM benefit from the Internet and WWW?

3.4.4.1 SCM supporting WWW development process

The support of activities related to Web processes is a major problem facing SCM. The Web itself meets a number of challenges related to CM.

According to [29], these include speed of change, variant explosion, dynamic content, and process support. These challenges also define the requirements for SCM. Many vendors are aware of these requirements and of the large opportunities presented. To remain competitive, they include WWW support in their SCM tools. The first three of these challenges determine somewhat different goals usually defined by SCM. Instead of emphasizing traceability, the application of an appropriate amount of work is the most important item. Artifacts with a short life (days or even just hours, such as Web pages) should be managed as simply and as quickly as possible, while more critical data should be treated in a more deliberate and thorough manner.

Most SCM tools provide support for mapping the structures of Web pages to SCM structures. Some vendors [30] speak of Web-object management, defining CIs on the higher abstraction level. In a Web application, we find different types of Web objects, including programs (Java and ActiveX typically on the client side), graphics, sound, video, links, and HTML, which usually but not always encapsulates simple text. Web objects contain these artifacts, different in form and thus differently treated by SCM (e.g., in versioning, merging, and diffing). One of the several books discussing support for WWW processing is [29]. In this book, the challenges, requirements, and SCM processes for managing Web pages are described in detail.

3.4.4.2 SCM and WWW—WebDAV

One example of version control utilizing WWW technology is WebDAV. WebDAV defines an extension to the hypertext transfer protocol (HTTP) permitting distributed Web authoring tools to be broadly interoperable. WebDAV also provides a network protocol for creating interoperable, collaborative applications. Major features of WebDAV are:

• Locking and versioning (concurrency control). Versioning support, similar to that provided by RCS, supports operations such as check out, check in, and retrieval of the history list.

• Properties. XML properties provide storage of arbitrary metadata ( similar to PDM metadata), such as a list of authors of Web resources.

• Namespace manipulation. Because resources may need to be copied or moved as a Web site evolves, WebDAV supports copy and move operations. Collections, similar to file system directories, may be created and listed.

How does WebDAV support geographically dispersed teams of Web site authors and developers? Web sites typically collect information from diverse sources, often from people who are geographically separated. Using a WebDAV server, the HTML pages, images, and other information that constitutes a Web site can be directly authored by the primary sources of the information. By using WebDAV functions, the tools may work transparently on a local network or on the Internet, making it possible to show the distributed environment as a local environment.

3.4.5 Component CM

A new paradigm in the development process has been recognized in recent years, from complete in-house development to a development process focused on the use of standard and de facto standard components, outsourcing, and commercial-off-the-shelf (COTS) products. The products are not closed, monolithic systems, but are components that may be integrated with other products available on the market. Software systems based on standard components are the results of a combination of development and the integration of existing components. The requirements for conventional use of SCM remains, but new requirements related to component management appear in all phases: in the design, integration, and during run time. The integration part (i.e., configuration) and version management of the components becomes more important. New aspects of SCM arise in the run-time phase, as components usually are loosely coupled and can be replaced or updated in the run-time environment. The basic requirements of component-based systems are identification of components and their remaining under version control.

Closely related to component CM is the product line development approach. In a product line, many variations of products are built from a number of core components always present in the products and many optional components or different variations of components. In component identification, selection, and the integration process, CM plays an important role. SCM methods are yet to be established in product lines. Problems in both component management and product lines are similar and deal with identification and structures, which approaches similar problems (and maybe solutions) present in PDM.

3.4.6 SCM process

By the late 1990s, the basic problems involving version, selection, and workspace management had been solved, and support for medium-size projects had been established. Support for large-size development projects came into focus. One of the main challenges with large projects is to keep track of the project’s process. Process issues also become interesting with the wide acceptance of the CMM ^. from industry. CMM ^. classifies the ability of companies to develop software on five levels. Each level identifies several crucial processes (key areas) that must function in the organization. One of the basic functions of level 2, at which the companies should be able to repeat a development project, is SCM. Many SCM vendors claim today that they support CMM ^. level 2 in general. By including process support, SCM has enlarged its area of operations. SCM support is focused not only on developers and tools for automation of certain actions, but also on management, planning, and project follow up. An SCM plan, including planning for resources, efforts, SCM milestones (most often baselines), and even SCM metrics, becomes a standard part of project documentation.

In the late 1990s, many organizations began to improve their processes by following CMM .. Consequently, they began using SCM tools and, more importantly, began planning for SCM activities in development projects, identifying SCM activities, and allocating resources.

3.4.7 Integrated environments

During the last decade, most SCM tools have been transformed. Once large, cumbersome, expensive, complex and user unfriendly, and, in particular, isolated from other tools, they became more user friendly, easier to deploy, and much better integrated with other engineering tools. Much remains to be done, particularly with respect to integration with other tools. As this is more a practical marketing issue, it is of primary interest for vendors rather than for researchers, among whom the widespread opinion is that in principle, the problem is solved. The main idea of integration is to conceal SCM as much as possible in the developer’s everyday work. For example, many SCM tools have an API compatible with Microsoft Visual Source Safe, which makes it easier to integrate with Microsoft Visual Studio. No standardized API for SCM functions is available as yet.

---