Hitchhiker's Guide to DRTS

Return to DRTS Info Page


Introduction

The Distributed Revision Tracking System (DRTS) from ILSI is a suite of code management tools that allow individuals and teams to work in parallel to speed the software development process. DRTS is designed to ease software version and revision control and simplifies release integration.

The tools are based on the powerful ''Copy-Modify-Merge'' model for software development. With this model, each user obtains a copy of the original source files, modifies those copies, and then merges the modifications with the originals. DRTS automatically tracks which files have been copied and modified by each user, and automatically detects when multiple users modify the same source files. Powerful tools are provided to merge changes from multiple users into a single source file.

Distributed aspects of the system allow project files to be shared between loosely connected development sites, and across disparate hardware and operating system platforms. The tools currently run on Intel 80X86 platforms running DOS and SCO UNIX, and on Sun Sparc platforms running the SunOS operating system.

Return to index


DRTS Environments

A key concept in DRTS is an environment, which is a collection of project related files under revision control. Each DRTS environment consists of an environment directory and a control point directory. The environment directory is where DRTS maintains multiple revisions of project files, and is not directly manipulated by the user. The control point directory is where the user modifies working copies of project files. The relationship between the control point and environment directories are shown below:

The control point directory allows the user to view selected revisions of project files contained in the environment directory. Within the control point directory, the user performs basic revision control operations such as checking out and checking in files. When a file is checked out, the specified revision is copied from the environment directory to the control point directory to be modified by the user. When a new revision is created by checking a file back in, the environment directory is updated with the new revision. The control point directory defines the root of a project directory structure. Under the control point directory, arbitrary directory structures can be used to organize project files. DRTS automatically maintains the environment directory to mirror the directory structure under the control point.

Each DRTS environment is organized into components, which are structured the same as the project directory tree. Components, like directories, contain files and other components. DRTS environments can contain all project files or a subset of the project files by specifying the appropriate components when the environment is created.

DRTS environments can be organized in a hierarchical tree-like fashion. A typical DRTS environment organization consists of three levels: release, integration and development as shown below:

In this organization, the top-level environment is used to capture system releases. The second level serves as an integration environment for user environments where the project development actually occurs. While this is a typical organization, the actual organization is arbitrary.

In DRTS environment hierarchies, an environment can be a parent environment, a child environment, or both. In the above diagram, the release environment is the parent environment of the integration environment. Similarly, the integration environment is the parent of the development environments, while at the same time being a child of the release environment. Any DRTS environment can have zero or more child environments. However, an environment can have at most one parent.

Return to index


Propagating Changes Between Environments

Each DRTS environment provides a private view of its parent. Any changes made in a child environment are kept local until they are moved up to the parent when a reconcile command is executed. Similarly, changes made to a parent environment can be brought down to a child environment through the use of the resync command. The following diagram shows the flow of changes between parent and child environments:

The reconcile command moves changes from a child environment to its parent. Before a reconcile can take place, the system ensures that the child environment has incorporated all the latest changes made to the parent. If there are any changes in the parent which have not been incorporated into the child, the reconcile command will issue warnings, and the user must first perform a resync.

The resync command brings down changes from a parent environment. When changes have occurred to different project files, resync simply updates the corresponding files in the child environment. When the same project file has been modified in both parent and child since the last resync, resync identifies a conflict. The conflict must be resolved by the user in the child environment. A merging utility is provided to merge the two sets of changes into a single source file. Once all changes from the parent have been incorporated, and all conflicts resolved, changes from the child can be reconciled to the parent.

Return to index


Distributed Development

An important property of DRTS environments is that each environment is totally self-contained. Within a child environment, the user has complete control of project files using the revision control capabilities of the system. The parent environment must be accessible only when the reconcile and resync operations are performed. These properties allow project teams to perform distributed development without any loss of system capability. Consider the following distributed DRTS environment hierarchy:

The dashed lines indicate transient connections between the various machines. For example, the UNIX workstation could be physically located in a different city or state. Changes to the local environment can be made without any network connection to the server. When the reconcile and resync operations need to be performed, a file system on the server is mounted using NFS (Network File System) to make the parent environment visible. Another example is to copy an environment onto a laptop PC. The complete environment can then be brought to a customer site to debug problems. This allows project files to be modified off-site without fear of losing changes.

DRTS maintains environment directories such that they are platform independent. This allows DRTS running on different platforms to access the same physical environment directories in a seamless fashion. When an environment is created, an attribute is assigned which indicates the platform. When updating files in an environment, DRTS honors the conventions of the native platform for that environment. For example, when a text file is copied from a DRTS environment created on a DOS platform to a DRTS environment created on a UNIX platform, a translation occurs. This is because DOS uses cr/lf (carriage return/line feed) pairs to terminate text lines, whereas UNIX text files use a single lf character. Because of this property, it is perfectly acceptable to physically copy DRTS environments from one platform to another.

Return to index


Further Information

DRTS is available today in both single and multi-user licenses for DOS and UNIX platforms. Further product and pricing information is available:


Order DRTS
Return to DRTS Info Page

Copyright © 1995 ILSI