[p4] Perforce keyword expansion

[Schlueter, Michael]

Hi,
I just found out that the perforce keyword expansion even replaces the
keywords normal c++ constant strings. It took me quite while to find out
that somewhere in a parser syntax definition a $date$ was replaced by the
current date. Is this a bug or feature? Is there a way to avoid this?

Michael

--
Michael Schlüter
secunet
Security Networks AG Tel : [phone]
Im Teelbruch 116 Fax : [phone]

D-45219 Essen E-Mail: ***@secunet.de

[Arnt Gulbrandsen]

Post by Schlueter, Michael
Hi,
I just found out that the perforce keyword expansion even replaces the
keywords normal c++ constant strings. It took me quite while to find out
that somewhere in a parser syntax definition a $date$ was replaced by the
current date. Is this a bug or feature?

It's a feature, usually used like this:

const char ident[] = "$Id$";

Many unix machines have a program called 'ident' that will print the
version strings that went into a linked executable.

Post by Schlueter, Michael
Is there a way to avoid this?

Not short of turning off keyword expansion. Perforce doesn't know c++
syntax (or that of any other language, AFAIK).

I have been troubled by it a few times. ISTR I once had a function that
searched for "$Id$" and of course that function's search string got
changed. But it's never been very difficult to work around the problem.

If you're using plain C++, maybe you can use the preprocessor's string
concatenation: "$Da" "te$" is the same as "$Date$".

--Arnt

[Peter Jaeckel]

Hi,

Perhaps another solution in this special case would be to switch
the type from k+text to ko+text this will only substitute $Id$ and
$Header$.

Cheers,
Peter Jaeckel

-----Original Message-----
From: Arnt Gulbrandsen [mailto:***@gulbrandsen.priv.no]
Sent: Dienstag, 4. Dezember 2001 14:03
To: Schlueter, Michael
Cc: 'perforce-***@perforce.com'
Subject: Re: [p4] Perforce keyword expansion

Post by Schlueter, Michael
Hi,
I just found out that the perforce keyword expansion even replaces the
keywords normal c++ constant strings. It took me quite while to find out
that somewhere in a parser syntax definition a $date$ was replaced by the
current date. Is this a bug or feature?

It's a feature, usually used like this:

const char ident[] = "$Id$";

Many unix machines have a program called 'ident' that will print the
version strings that went into a linked executable.

Post by Schlueter, Michael
Is there a way to avoid this?

Not short of turning off keyword expansion. Perforce doesn't know c++
syntax (or that of any other language, AFAIK).

I have been troubled by it a few times. ISTR I once had a function that
searched for "$Id$" and of course that function's search string got
changed. But it's never been very difficult to work around the problem.

If you're using plain C++, maybe you can use the preprocessor's string
concatenation: "$Da" "te$" is the same as "$Date$".

--Arnt
_______________________________________________
perforce-user mailing list - perforce-***@perforce.com
http://maillist.perforce.com/mailman/listinfo/perforce-user

[Simon Morton]

Post by Schlueter, Michael
I just found out that the perforce keyword expansion even
replaces the keywords normal c++ constant strings.

[snip]

Post by Schlueter, Michael
Is this a bug or feature?

It is absolutely a feature. Embedding keywords in string constants
means you can access them programmatically and print/display them from
within the application, say in a title bar or in response to a -v
option. It also means that they persist in the binary forms of the
application so that you can use strings or ident to extract them and
find out which version(s) you are really dealing with.

static const char rcsid[] = "$Id$"; is the oldest trick in the book.

On this subject, though, does anyone know why perforce only expands
$Id and $Header to give file and version? In RCS they give much more
information.

[Todd Short]

I am sure there will be others that respond to this, but in 2001.1:

filetype:

text+ko: Old style keyword expansion: $Id$ and $Header$.
text+k: Keyword expansion: $Id$, $Header$, $Date$, $DateTime$, $Change$,
$File$, $Revision$, $Author$

In versions prior to 2001.1, text+k only did $Id$ and $Header$. There was no
text+ko type.

--
-Todd Short
//***@cisco.com
//"One if my land, two if by sea, three if by the Internet."


-----Original Message-----
From: perforce-user-***@perforce.com
[mailto:perforce-user-***@perforce.com]On Behalf Of Simon Morton
Sent: Wednesday, December 05, 2001 11:06 AM
To: 'Schlueter, Michael'; 'perforce-***@perforce.com'
Subject: [p4] RE: Perforce keyword expansion

Post by Schlueter, Michael
I just found out that the perforce keyword expansion even
replaces the keywords normal c++ constant strings.

[snip]

Post by Schlueter, Michael
Is this a bug or feature?

It is absolutely a feature. Embedding keywords in string constants
means you can access them programmatically and print/display them from
within the application, say in a title bar or in response to a -v
option. It also means that they persist in the binary forms of the
application so that you can use strings or ident to extract them and
find out which version(s) you are really dealing with.

static const char rcsid[] = "$Id$"; is the oldest trick in the book.

On this subject, though, does anyone know why perforce only expands
$Id and $Header to give file and version? In RCS they give much more
information.

[w***@us.itmasters.com]

Post by Todd Short
In versions prior to 2001.1, text+k only did $Id$ and $Header$. There
was no text+ko type.

That was supported at least as far back as 2000.2 (and I think 2000.1 as
well). -Wm

[twardst]

Or still one more solution, that I have an enhancement request in for is to
add a new keyword that would turn off keyword expansion for the remainder
of the file.

tim

Post by Peter Jaeckel
Hi,
Perhaps another solution in this special case would be to switch
the type from k+text to ko+text this will only substitute $Id$ and
$Header$.
Cheers,
Peter Jaeckel
-----Original Message-----
Sent: Dienstag, 4. Dezember 2001 14:03
To: Schlueter, Michael
Subject: Re: [p4] Perforce keyword expansion

Post by Schlueter, Michael
Hi,
I just found out that the perforce keyword expansion even replaces the
keywords normal c++ constant strings. It took me quite while to find out
that somewhere in a parser syntax definition a $date$ was replaced by the
current date. Is this a bug or feature?

const char ident[] = "$Id$";
Many unix machines have a program called 'ident' that will print the
version strings that went into a linked executable.

Post by Schlueter, Michael
Is there a way to avoid this?

Not short of turning off keyword expansion. Perforce doesn't know c++
syntax (or that of any other language, AFAIK).
I have been troubled by it a few times. ISTR I once had a function that
searched for "$Id$" and of course that function's search string got
changed. But it's never been very difficult to work around the problem.
If you're using plain C++, maybe you can use the preprocessor's string
concatenation: "$Da" "te$" is the same as "$Date$".
--Arnt
_______________________________________________
http://maillist.perforce.com/mailman/listinfo/perforce-user
_______________________________________________
http://maillist.perforce.com/mailman/listinfo/perforce-user

[Simon Morton]

I was just wondering why the content of the $Header and $Id tags in perforce
was not more similar to RCS.

I.e. In perforce (2001.1):

$Header: //depot/web/apache/htdocs/index.html#5 $

In RCS:

$Header: /home/simon/hello.c,v 1.2 2001/12/05 18:02:26 simon Exp simon $


Simon

-----Original Message-----
From: ***@us.itmasters.com [mailto:***@us.itmasters.com]
Sent: Wednesday, December 05, 2001 12:01 PM
To: perforce-***@perforce.com
Subject: RE: [p4] RE: Perforce keyword expansion

Post by Todd Short
In versions prior to 2001.1, text+k only did $Id$ and $Header$. There
was no text+ko type.

That was supported at least as far back as 2000.2 (and I think 2000.1 as
well). -Wm

[Todd Short]

My mistake... 2000.1 (which looks a lot like 2001.1).

So, if you are < 2000.1

text+k = $Id$ and $Header$ keyword expansion

Otherwise, you are >= 2000.1

text+ko = $Id$ and $Header$ keyword expansion
text+k = $Id$, $Header$, $Date$, $DateTime$, $Change$, $File$, $Revision$,
$Author$

To automatically specify file types when files are added, use the 'p4
typemap' command.
In general, it is probably a good idea to use the 'p4 typemap' command even
if you are not going to use keyword expansion. We had a few files that were
originally added as 'binary' because they contained a character in the upper
128 bytes of the ASCII space (I believe it was a copyright symbol), so
Perforce looked at the file and must've thought it was binary... This, of
course, has been pains when tying to diff the file, or use the p4pr
script...
--
-Todd Short
//***@cisco.com
//"One if my land, two if by sea, three if by the Internet."

-----Original Message-----
From: perforce-user-***@perforce.com
[mailto:perforce-user-***@perforce.com]On Behalf Of ***@us.itmasters.com
Sent: Wednesday, December 05, 2001 12:01 PM
To: perforce-***@perforce.com
Subject: RE: [p4] RE: Perforce keyword expansion

Post by Todd Short
In versions prior to 2001.1, text+k only did $Id$ and $Header$. There
was no text+ko type.

That was supported at least as far back as 2000.2 (and I think 2000.1 as
well). -Wm

[Gordon Broom]

Post by Simon Morton
I was just wondering why the content of the $Header and $Id tags in

perforce was not more similar to RCS.

Post by Simon Morton
$Header: //depot/web/apache/htdocs/index.html#5 $
$Header: /home/simon/hello.c,v 1.2 2001/12/05 18:02:26 simon Exp simon $

OK, I think this might be a useful feature enhancement: have $Header$
expansion work in a similar way to RCS when the file in question is open for
edit. By this I only mean adding the username when the file is checked out,
not adding all the other information present in the RCS keyword. Something
like this:

$Header: //depot/path/to/file#1 $ <== file is not checked out for
edit
$Header: //depot/path/to/file#1 gordonb $ <== file is checked out for
edit, by 'gordonb'.

This gives you the ability to see at a glance which files in your
end-product have not been submitted (and thus cannot be reproduced). Right
now you can't tell if //depot/path/to/file#1 is the actual revision #1, or
an edit to revision #1 in a pending changelist.

The drawback I see to this approach is that it involves transferring another
copy of the file down from the server upon "p4 edit", rather than just
twiddling a permission bit.

This is less of a concern when you use an automated build process, in which
all files are synched from the depot before building, and thus have been
submitted. If you don't have the infrastructure, however, you can
occasionally slip up and forget to submit a file before rolling it out (e.g.
the automated build scripts themselves are stored in Perforce, and you end
up with a chicken/egg problem).

<***@pwrm.com>
CM Engineer -- Development Automation Team
Power Measurement <http://www.pwrm.com/>
[phone] x7608