[p4] RCS keywords

Dave Lewis dlewis78731 at gmail.com
Thu Nov 9 15:25:16 PST 2006


For a lot of in-house stuff, I would just set up a client and
sync it when I wanted to release stuff. It is very handy.

dave

On 11/9/06, David Alban <dalban at stubhub.com> wrote:
> 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
>
> _______________________________________________
> 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