[p4] RCS keywords
dalban at stubhub.com
Thu Nov 9 09:41:49 PST 2006
Thanks for your response, Robert.
I can see now that my tendency toward using the keywords most likely
comes from the fact that I develop mostly standalone tools that aren't
part of anyone else's releases. They're shell and perl tools, so there
aren't any binary library or executable files.
I think I will take advantage of perforce's keyword expansion capability
for my tools, which will either not be a part of a release, or will be
such a small part that they won't adversely affect perforce performance.
And I promise not to blink when the developers don't use them for their
larger projects, or even know what they are.
David Alban <dalban at stubhub.com>
Release Engineering Tools
From: Robert Cowham [mailto:robert at vaccaperna.co.uk]
Sent: Thursday, November 09, 2006 2:08 AM
To: David Alban; perforce-user at perforce.com
Subject: RE: [p4] RCS keywords
There are several factors at work:
- expanding keywords adds overhead to submits and other processing - so
larger projects it may not be worth it (tens or hundreds of thousands of
files) for all files
- once you get used to it, thinking in terms of changelists rather than
individual file versions makes life much more manageable. This leans
using changelist reporting on the repository (not always so useful if
are on site with no direct access and having to hack around code, but
a separate issue!)
- in many cases, all you need to track is the branch and changelist
that branch. A good method is to "compile it in" as part of your build
process. This allows tracing back to the precise configuration used to
build. (Eg. Run "p4 changes -s submitted -m 1 ..." to find last
number and process the returned value).
- what are you releasing? Binaries? Source files? Combination? How are
If releasing binaries I would tend to go for the build approach. For an
with source files, perhaps keyword expansion or the Perforce approach.
If releasing source files (e.g. to a web site) I would really want to be
doing this by syncing direct out of Perforce at which point I can track
state of the client workspace.
- Note that Perforce themselves with their API include a Version file
values such as changelist are manually updated, rather than generated at
I myself turn on keyword expansion for some small projects, and use the
other approaches for larger ones.
> -----Original Message-----
> From: perforce-user-bounces at perforce.com
> [mailto:perforce-user-bounces at perforce.com] On Behalf Of David Alban
> Sent: 09 November 2006 01:55
> To: perforce-user at perforce.com
> Subject: [p4] RCS keywords
> 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.
> David Alban <dalban at stubhub.com>
> Release Engineering Tools
> perforce-user mailing list - perforce-user at perforce.com
More information about the perforce-user