[p4] RCS keywords

Robert Cowham robert at vaccaperna.co.uk
Thu Nov 9 02:07:30 PST 2006


There are several factors at work:

- expanding keywords adds overhead to submits and other processing - so with
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 towards
using changelist reporting on the repository (not always so useful if you
are on site with no direct access and having to hack around code, but that's
a separate issue!)

- in many cases, all you need to track is the branch and changelist along
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 changelist
number and process the returned value).

- what are you releasing? Binaries? Source files? Combination? How are they
being used?

If releasing binaries I would tend to go for the build approach. For an API
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 the
state of the client workspace.

- Note that Perforce themselves with their API include a Version file where
values such as changelist are manually updated, rather than generated at
build time

I myself turn on keyword expansion for some small projects, and use the
other approaches for larger ones.

Robert

> -----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
> 
> 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