File and thread attributes

File and thread STATEs

As a development effort proceeds, the various files involved will go through numerous modifications. It is often handy as well as necessary that you have the ability to assign various levels of trust to particular versions of each file. The most recently edited form may not be the most highly tested or trusted. This is accomplished through the use of a STATE attribute.

Although defined in the Attributes file much like a ONE_OF_MANY, these special attributes are used as historical markers, rather than indicators of the present status of a file under control. The STATE attribute is best described by example.

In the following flow, we'll assume that a Razor group has been configured to provide four distinct levels of blessings for the files under control. These would appear in the related Attributes file as follows...

STATEStateActive, Compiled, Tested, Released

The Active state is the lowest level of trust and it implies that the related version of the file is in a dynamic state. The Compiled state implies that the related version can pass through the compiler without any problems and that it conforms to various in-house coding standards. If a version is Tested, then it has successfully completed a series of quality control measures. Finally, if a version of a file has been promoted to the Released state, then it has actually been incorporated into a product release.¹

In the following diagrams, the squares represent a file that is being modified over time, with each check-in yielding a higher version number for the file. The various states can be thought of as placards which travel on a wire over the history of changes occurring to the file under control




In this scenario, our developer (Latka) reaches a nice break point in his efforts and now has a version of the file which he believes compiles nicely and meets all of the necessary coding standards. He is able to promote² the latest version of the file to the Compiled state and is free to continue on with other work. As he does this, he notifies his friend Louie in SQA that the file is ready for testing.

Since Louie is able to easily obtain a read-only copy of any file at any version, Latka is indeed free to proceed with his development efforts. His ongoing modifications to the file will not affect Louie's tests.




After some time, Louie may flag version 1.3 of the file as being tested. Independently, Latka may well have moved on and identified a subsequent version as being Compiled, while he has progressed further on with yet more edits.




Since the various state placards are left associated with unique file version numbers, there is no danger in having the developers proceed with their work. In fact, taking advantage of this paradigm, developers become much more likely to occasionally checkpoint their efforts into the archival system, allowing users to welcome and rely on the system rather than avoid it.

Defining who may promote files/threads

Razor allows you to easily restrict who may perform the promotion of various versions of files and threads from one state to another. Only those users defined in the database/file control group (i.e. versions group or threads group) Tables/Promoters³ are allowed to do promotions (i.e., a list of userid's, user groups, and or defined roles). The syntax of the file requires that each userid be called out on its own line. To limit promotion to Jerry, George, and Elaine; the Promoters file would look like...

jerry
george
elaine

The default is to allow all users to promote files, denoted by an asterisk ("*") on a line by itself.

NOTE: The Promoters file is superseded by the Access_list file but is left for backward compatibility. Users should switch to Access_list, described on page 199, as subsequent versions of Razor may not support Promoters.

Associating glyphs to file attributes

As noted earlier in the manual, it is possible to associate glyphs to represent the settings of the various ONE_OF_MANY attributes related to a file or thread under control. These glyphs will appear on the left side of the main scrolling display of the versions program, providing quick visual insight to the nature of the file.

To define the glyph usage, you need to edit the file $RAZOR_UNIVERSE_DIR/DOMAIN_01/<file control group>/Tables/ Bitmaps. Each line defines a relationship between an attribute value and a glyph. Three tab separated fields are needed for this, as shown below:

<label><value><glyph_file_name>

For example, if you defined an attribute in the Attributes file which indicated which library the related source code belonged to...

ONE_OF_MANYLib---, GUI, Math, Comm, Dev

...then you could have glyphs hinting of the relationship. The corresponding lines in the Bitmaps file would read...

Lib  GUI   $RAZOR_HOME/glyphs/star_0.xbm
Lib  Math  $RAZOR_HOME/glyphs/symbol_hash.xbm
Lib  Com   $RAZOR_HOME/glyphs/symbol_bang2.xbm
Lib  Dev   $RAZOR_HOME/glyphs/weather_sun.xbm

¹ Please note that the states discussed here are purely for illustration only. You may opt to incorporate a much more sophisticated scheme, or none at all.
² The actual mechanics of promoting a file are discussed elsewhere. See "Promoting specific versions" on page 106.
³ See "Promoters (versions & threads only)" on page 270.