NAME

VcsTools::DataSpec::HpTnd - Perl class to translate Hp Tnd HMS log to info hash

SYNOPSIS

my $ds = new VcsTools::DataSpec::HpTnd ;

my @log = <DATA>;
my $info = $ds->analyseLog(\@log) ;

my $piledInfo = $ds->pileLog('pile test',
                             [
                              [ '3.10', $info->{'3.10'}],
                              ['3.11', $info->{'3.11'}],
                              ['3.12', $info->{'3.12'}],
                              ['3.13', $info->{'3.13'}],
                             ]
                            ) ;
print $ds->buildLogString ($piledInfo);

DESCRIPTION

This class is used to translate the log of an HMS file into a hash containing all relevant informations and vice-versa.

The $logDataFormat hash ref also defines the informations that are contained in the log of each version of the HMS file.

It can also concatenate several logs into one according to the rules defined in the $logDataFormat hash.

Needless to say this file is tailored for HP Tnd needs and HMS keywords. Nevertheless, it can be used as a template for other VCS systems and other needs.

Contructor

new()

No parameters.

Methods

analyseLog(array_ref)

Analyse the history of a file and returns a hash ref containing all relevant informations. The keys of the hash are made from the revision numbers found in the history log.

Each element of the passed array must contain one chomped line of the history.

getDataFormat()

Return the hash ref defining the data format.

buildLogString($info_hash_ref)

Returns a log string from the info hash. The log string may be archived as is in the HMS base.

pileLog(file_name, [ [ rev, info_ref], ... ])

Returns an info hash made of all informations about revision passed in the array ref.

file_name is the name of the concerned Vcs file. This field is necessary to build a readable cumulated log.
The second parameter is an array ref made where each element is an array ref made of the version number and the info hash ref of this revision. (See example below)

DATA FORMAT

See VcsTools::HistEdit(3).

Each data item may also have a 'pile' element which specify how the information are cumulated.

For array data type, it can be 'push'. In this case, the array elements are pushed, then sorted and redundant infos are discarded.

For text data type, is can be 'concat'. In this case, the text strings are concatenated together and with each file name and revision number.

HP TND DATA

state

Taken from 'state' HMS field. It can be either Dead Exp Team Lab 
Special or Product according to the level of confidence.

date

Date of the archive. Set by HMS. read-only value.

merged from

Specifies if this version is a merge between the parent revision and another revision.

comes from

Explicitely specifies the parent revision. Use this field when the parent cannot be infered. For instance, when the revision number jump from 1.19 to 2.1, set the 'comes from' field of the revision '2.1' to '1.19'.

writer

The original writer of this version. Since HMS changes the author field whenever you edit the history of a version, this field keeps track of the guy who actually archived this version.

keywords

Keyword which refers to the functionnality added in this version. (could be 'ANSI', 'cosmetic', 'doc_update' ...).

fix

Official names of the bugs fixed in this version (a la 'GREhp01234').

misc

Miscellaneous comments about this version.

CHANGE MODEL

The 3 following keywords try to provide a model for changes introduced with each revision of a file.

behavior change

Specify whether this code can smoothly replace the previous revision. Can be 'none', 'cosmetic', 'minor','major'

Still need a clear definition of what it means.

interface change

Specify the amount of change seen from the compiler's point of view. For a header file, for instance, 'cosmetic' might mean 're-compilation needed', 'major' might mean 'code change needed in user code'.

Can be 'none', 'cosmetic', 'major'

inter-peer change

Specify whether this code can inter-work with the previous revision.