Rational Team Concert - version numbers / keyword expansion

Question

I am trying to create an automatic build package which the build version embedded.

The version control system in use is RTC.

As far as I can see there is no keyword expansion, nor file version numbers. On the RTC forum someone replied (pp) "there is no need for keyword expansion in RTC because it offers more reliable mechanisms to determine file history".

Quite what the mechanism is I don't know. Odd also that RTC doesn't do version numbers, yet RTC itself has aversion number (e.g RTC 3.0).

Alternative is to have a text file with this info and increment it myself.

Answer 1

there is no need for keyword expansion in RTC because it offers more reliable mechanisms to determine file history

RTC makes change set/baseline, which means if you know what change set or what baseline the file you see comes from, you can find its history.

The is a work item tracking that feature: Enhancement 43191

Keyword expansion mess-up merges and makes conflict resolution hard.
But I know people like having that little tag at the bottom of an html page. The alternative is to add the keywords and have a build step (eg, some ant script) which calculates the substitution.

I don't know all the possible keywords for substitution in cvs and cmvc I would expect to be able to customize the substitution in my build definition, with published suggestions for CMVC and CVS.
That way I can make versionid be any combination of available properties.
Just provide the list of available properties and let the users pick.. so %Z% -> "@(#)" and %W% -> ${rtc.filename} or whatever.
Just document them like in "Getting Started with setting up Jazz Builds".
I guess what I'm saying is don't delay the item because we can't provide all the mappings. If something doesn't map, we could map it to something else or to blank.

We have a command line and ant task that may be able to help you out, we use this to help decide if we should increase version qualifiers, it's called "lastMod".
It basically checks the diff between two baselines and returns the timestamp of the latest change. If there are no changes, the timestamp won't change.
This requires that baselines are created at regular intervals, but may help you out in the short term