It's all about the answers!

Ask a question
QuestionsTagsUsersBadges
Follow this question
Question details

×42,788

question asked: Jun 13 '11, 10:38 a.m.
question was seen: 4,905 times
last updated: Jun 27 '18, 5:56 p.m.

Related questions

FAQ - How this Forum works

File header substitution on check-in ( i.e. - $Header:$ )

1
Doug Griswold (16●1●2) | asked Jun 13 '11, 10:38 a.m.
In CVS we include a comment line with the string "$Header:$" at the top of the file. Then when we check a file in with this line, several pieces of information are substituted and updated. For example:
<!-- $Header: /cvsroot/myProject/abc/config/policy-R3p0.xml,v 1.33 2011/04/26 21:15:21 griswold Exp $ -->

where:

o "/cvsroot/myProject/abc/config/policy-R3p0.xml" is the library path where the updated file is stored
o "v 1.33" indicates this is version 33. This number is automatically incremented every time a change to the file is checked in
o "2011/04/26 21:15:21" timestamp when the change was checked in
o "griswold" userid that checked in the change

We use XML files extensively to specify configurable settings. Having a watermark inside the file to show its version and who and when it was last changed it is an important feature for us.

Is there a similar feature in RTC? If so what needs to be done to enable it? I'm using RTC 3.0 client.

Thanks.
Comments
Kevin Behrens commented Jun 22 '11, 11:22 a.m. | edited Jun 27 '18, 5:54 p.m.

I think the keyword substitution redundantly duplicates information, the metadata is in the source control system. It's a holdover that the SVN project picked up when trying to develop a drop in replacement for CVS.

The XML still has to be deployed somewhere - is it just a checkout from RTC? It wouldn't be a lot of work to have the script that does the checkout add some version information to the files when a package is created or when the files are deployed.

I know it's silly but I don't like having to scroll through that junk, and really dislike the cruft in diffs (though the eclipse IDE will likely handle those intelligently). It seems there is always some guy who wants a block 20 lines long.

Accepted answer

0
permanent link
Geoffrey Clemm (30.1k●3●30●35) | answered Jun 27 '18, 5:51 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

Note that the expansion of the following keywords is available in RTC 6.0.5:

The following keywords are supported:

$VersionId$ - The version ID of the file.

$LongVersionId$ - The long version ID of the file (for example: VersionId@repoId).

$ItemId$ - The UUID that identifies the file.

$StateId$ - The UUID that identifies the specific state of the file.

$Date$ - The date that the file in the repository was most recently modified.

$Name$ - The name of the file in the repository.


Geoffrey Clemm selected this answer as the correct answer

4 other answers

Most liked answers ↑|Newest answers|Oldest answers

1
permanent link
Geoffrey Clemm (30.1k●3●30●35) | answered Jun 13 '11, 12:52 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
edited Jun 27 '18, 5:52 p.m.

This functionality is requested in work item 43191.
Note that while you are working in RTC, you have all of this information
directly from RTC, and there is no need to have this meta-data stored in
the text of the file. But when you are releasing the file to the outside
world is when you need it, so the current workaround is to do this
keyword substitution as a build step, prior to compiling/distributing
the file.
0
permanent link
Doug Griswold (16●1●2) | answered Jun 22 '11, 9:44 a.m.
edited Jun 27 '18, 5:52 p.m. by Geoffrey Clemm (30.1k●3●30●35)

Thank you for the pointer to the requirement.

Would like to add a clarification here - we use RTC (and previously CVS) for source control, but not for builds. Note that our source is not java, C++, etc., therefore a build-time solution will not meet our needs. 
0
permanent link
Geoffrey Clemm (30.1k●3●30●35) | answered Jun 22 '11, 7:59 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
edited Jun 27 '18, 5:55 p.m.

Let's continue the discussion in work item 43191. (That makes it more
easily accessible to the development team).

0
permanent link
Geoffrey Clemm (30.1k●3●30●35) | answered Jun 22 '11, 8:01 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
edited Jun 27 '18, 5:55 p.m.

That is correct ... most modern SCM systems store this metadata
automatically and separately from the file content (so you don't have to
mess with the file content ... especially important if the file content
is binary, or if it is being digitally signed).

The only use case where I have found that it is still useful is to
annotate the code when it is being distributed outside the SCM system,
which is why the "build time" annotation is proposed ... i.e. store that
information in the appropriate files as one of the steps of distributing
those files to the external world.

Your answer

Register or to post your answer.


Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.