Design Update and Maintenance: Revision Control





Design Update and Maintenance: Revision Control

When a group of engineers work on a project consisting of many files, files change constantly while being accessed. It is imperative to have a system to manage multiple variants of evolving files and track revision, as well as manage the project environment so that only the stable and correct version combinations of the files are visible. This is where a revision control system comes in. A revision control system has two objectives: to grant exclusive write access to files and to retrieve versions of files for read consistent with a user configuration specification. The exclusive write access feature ensures that a file can only be modified by one person at any time. This prevents a file from being edited simultaneously by more than one user, where only one user's result is saved and the others' are lost. A file must first be checked out before it can be modified. Once a file has been checked out, it can no longer be checked out again until it is checked back in. A file can have many revisions.

When a file is accessed, the version of the file needs to be specified. A view of a project is a specification of versions, one version for each file. This specification determines a view and is sometimes called a configuration file. To access a particular version of a file, the user simply specifies the version number for the file in a configuration file. When a configuration file is activated to provide a view, only the files that meet the specifications in the configuration file are accessible. An example configuration is shown below. The first item is the name of a file, followed by the version used in this configuration. File all_RTL.h in this configuration has version 12.1. The last line indicates that any file without a specified version is assigned the version labeled RELEASE_ALPHA.

all_RTL.h version 12.1 // header file
CPU.v version 15.3 // top level CPU
itu.v version 15.3 // ITU block
* version ALPHA_RELEASE

Conceptually, a revision control system has the following key components and architecture, as shown in Figure. All files are stored in a centralized database. Each file is stored in a layered structure, with the bottom layer being the full content of the file. On top of it is a collection of incremental changes to the file. Each layer is labeled with a version number. A user environment is determined by a view with a configuration specification. To reconstruct files of particular versions, the view manager in a revision control system takes in a configuration file and dispatches each file and its version to a version handler, which reconstructs that version of the file from the layers in the centralized database.

15. Architecture and key components of a revision control system


When a file is checked out, a copy of the file is placed in the local file storage area and can be modified by the user. Any modification to that file is only visible in that view, and thus does not affect other users using that file in other views. When changes are finalized, the file is checked in. When a check-in command is issued to the view manager, it removes the file from the local file storage area and passes it to the version handler, which attaches a new version number to the file and stores it incrementally to the centralized file database.

Once a file is checked in, its newly updated contents can be visible by specifying in the configuration file the new version number assigned to the file.

In practice, a configuration specification file does not indicate a version for every file explicitly. Instead, files without an explicit version are assumed to be retrieved from a default version, such as the latest version. Furthermore, when a project arrives at a milestone release, all checked-in files at that milestone can be tagged with a label, say ALPHA_RELEASE, so that a view of this milestone release can be invoked by simply using label ALPHA_RELEASE, as opposed to the version numbers for the files.

In a large project, restricting editing of a file only to one user serializes development and hampers progress. When several engineers need to modify a file during the same period of time, copies of the file can be created through a branching process so that the engineers can work on it simultaneously. When a branch is created, the original version becomes the main branch. Files on any other branches are revision controlled in the same way as the main branch. When a branch of the file has reached stability, it can be merged with the main branch. When merging two branches, the version control system displays the two versions of the file, highlights the differences, and prompts the user to make decisions regarding which of the differences should go to the merged version. Figure is a diagram showing a file's revision history, in which the nodes represent versions and the file has been branched three times. The main branch forks at a side branch for DFT team at version 1.0. Branch DFT has two versions, D1.0 and D1.1, before it merges with the main branch at version 2.0. In other words, version 2.0 has all updates from the DFT branch. The DFT branch has its own subbranch for another group doing cross-clock domain enhancement. This xdomain branch merges with the main branch at version 3.0. Similarly, at version 1.1, a branch is created for simulation work that itself has three versions and later merges with the main branch at version 3.0. Version 3.0 is also labeled as RELEASE 1.0, denoting a milestone version. A branch is not restricted to merging only with the main branch; it can be merged with any other branch.

16. Version tree of a file showing versions, branches, and merges



     Python   SQL   Java   php   Perl 
     game development   web development   internet   *nix   graphics   hardware 
     telecommunications   C++ 
     Flash   Active Directory   Windows