[p4] RCS keywords

David Alban dalban at stubhub.com
Thu Nov 9 09:59:41 PST 2006


Thanks for your response, David.

What about simply including the keyword:

  $Change$

in my shell and perl tools?  That would at least let me associate
versions of files in the field back to their change list.

I'd like to track the source version rather than a release version.
These are in-house infrastructure tools.

-- 
David Alban <dalban at stubhub.com>
Release Engineering Tools
http://StubHub.com/

-----Original Message-----
From: Weintraub, David [mailto:david.weintraub at bofasecurities.com] 
Sent: Thursday, November 09, 2006 9:15 AM
To: David Alban; perforce-user at perforce.com
Subject: RE: [p4] RCS keywords

In RCS, Keywords were important because there was really no other way of
knowing what version of the source you were looking at. Once you moved
to more sophisticated software where you could query about the version
you're looking at, the value of having keywords in a development
environment was greatly diminished. This is especially true since
keyword expansion can get in the way of merging and diffing since many
merge and diff managers see differences in keywords as a merge conflict.

Keyword expansion could be helpful when attempting to determine the
version of the software installed on a client site. However, the
advantage of doing this had some pretty strict limits because the
version number pulled up may not tell you too much. For example:

    $Id: foo,v 1.2 2006/10/30 dalban $

This tells me that the source file used in compiling this program was
revision 1.2 of the file "foo". The problem is that this doesn't really
mean all that much. What would be much more helpful is seeing a
reference number that refers back to the versions of all the files that
were used and not just this one file. Revision 1.2 of the file "foo" may
have been involved in multiple software releases. I can't tell by
looking at this number whether I'm looking at Release 1.2 or Release 1.3
of my software since revision 1.2 of file "foo" is in both revisions.

A better way is to have your compilation routine insert a meaningful
release number or build number when you compile your code. Then, have a
function that allows me to extract this information from the code. For
example, I might look in an "About Box", or I could run the program with
a "--version" command line parameter, or I insert the version number in
such a way that it looks like a "what" string or an "ident" string.

It is interesting to see that modern version control systems like
Subversion and Peforce have keyword expansion off by default. ClearCase
doesn't even bother to implement this feature. Keyword expansion, like
"uucp" and "tip" are old Unix habits that have outlived their
usefulness.

-----Original Message-----
From: perforce-user-bounces at perforce.com
[mailto:perforce-user-bounces at perforce.com] On Behalf Of David Alban
Sent: Wednesday, November 08, 2006 8:55 PM
To: perforce-user at perforce.com
Subject: [p4] RCS keywords

Greetings,

I'm a unix person and so I'm used to seeing RCS keywords expanded in
comments in production versions of header files, scripts, config files,
etc.  I find that having something like:

  # $Id: foo,v 1.12 2006/10/30 19:36:47 dalban $

or similar at the top of a file helps me determine which version is
installed where.

I'm curious if the folks on this list choose to use perforce's
capability of expanding these keywords, or whether you have other
methods of determining which version of a controlled file is in
production.  Or, when you want to know, do you always go back to the
repository and get a checksum of the head (or other relevant) version of
the file to compare with that of the file in production.

Thanks,
David
--
David Alban <dalban at stubhub.com>
Release Engineering Tools
http://StubHub.com/

_______________________________________________
perforce-user mailing list  -  perforce-user at perforce.com
http://maillist.perforce.com/mailman/listinfo/perforce-user




More information about the perforce-user mailing list