Browse Prior Art Database

A Method for Record-Based Configuration Management Systems to Represent Non-Versioned Artifacts in the Context of a Configuration

IP.com Disclosure Number: IPCOM000244535D
Publication Date: 2015-Dec-18
Document File: 6 page(s) / 64K

Publishing Venue

The IP.com Prior Art Database

Abstract

Disclosed is a method for a record-based configuration management system (RCMS) to handle resource version updates such that the updates are persisted in the stream, but those flagged as internal do not otherwise participate in other CM operations.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 21% of the total text.

Page 01 of 6

A Method for Record-Based Configuration Management Systems to Represent Non-Versioned Artifacts in the Context of a Configuration

Tools that support managing and editing domain-specific artifacts in a record-based configuration management system (RCMS) require a method to track non-versionable artifacts as part of a configuration, while also ensuring that such artifacts do not participate in most other typical configuration management operations (e.g., branching a stream, creating a baseline, delivering change sets from one stream to another, etc.). In general, artifact versioning in record-based configuration management systems is not a widely addressed problem due to the technical challenges. File-based Software Configuration Management (SCM) systems might allow users to create files in a stream and flag the files to not be included in change sets that will be delivered to other streams. This is inherently different from a system that does allow artifacts to be delivered to the stream so other users can see the files, while not being included in operations such as baseline creation, stream branching, and change set delivery.

For example, consider a record-based tool that uses a configuration management system to manage its artifacts . This tool wants
to implement locking so that no two users can edit the same artifact in the same stream at the same time . Assume artifact A exists in hundreds of streams and baselines. Having a single lock associated with artifact A that is managed outside the context of a specific stream is too broad and would problematically lock out all users from modifying A in any stream when the lock is acquired by one person. Instead, a lock like this must be created within the specific relevant stream. However, such a lock is not a versionable artifact, as such. Multiple versions of the lock should not exist (it either exists or it does not); the lock should not be inherited when branching a stream; a user should not be able to deliver the lock to another stream, etc. However, internal artifacts such as this kind of lock do need to be inherited into
change sets that are created on a given stream. That is, if a user X has a lock on artifact A in a stream, and user Y creates a change set on that stream, then that lock should be visible and in effect for user Y.

The novel solution introduces an internal flag, which is a Boolean value that can be specified by a domain tool on a per-resource basis when it is updating the versions of resources in a stream in an RCMS. The solution introduces a method for the RCMS to handle resource version updates such that the updates are persisted in the stream but those flagged as internal do not otherwise participate in other CM operations.

For example, internal resource versions are not included in change sets when they are delivered from one stream to another . Therefore, and because the delivery protocol is change set-based, internal resources are implicitly excluded when...