begin quoting Lan Barnes as of Sat, Jul 19, 2008 at 10:12:59AM -0700:
>
> On Fri, July 18, 2008 8:07 pm, Carl Lowenstein wrote:
>
> > If I may allude to an old discussion, isn't this an argument for
> > embedding people-readable tags in object files?
>
> This is a clever and valid use of key words. Something like:
>
> static char* OBJVER="$Version";
>
> That's from dim memory, so it may be syntactically wrong, but it gets the
> idea across.
Yes. And if it's never used, an optimizing compiler may pull it out.
A fair bit of my Java code has stuff like:
/**
* blah blah blah
* @revision $Revision$
*/
public class Blah {
// blah blah blah
public static void main( String [] args ) {
System.out.println( CVS_ID );
}
public static final String CVS_ID =
"$Id$";
}
The @revision is a custom javadoc tag, which drops the $Revision$ string
into the generated documentation, and the $Id$ string is replaced with
the pathname and version information, embedded in the .class file, and
accessible from the command-line.
It's generally been less useful than I would have originally thought,
because if someone has a problem, we normally just give them the latest
known-working code.
> My problem with that, and with all key words is this: at check in/commit,
> the system will usually do a diff _before_ to see if the file's changed.
> But any diff _after_ will say the files are different, even if they
> aren't. A human can easily spot that it's just a key word, but it's plain
> hell to script:
>
> set return [exec diff $a $b]
> if {return != 0} {
> # do something
> }
>
> ... or ...
>
> set return [exec diff $a $b]
> if {return != 0} {
> if {[some goddam thing to scan for keywords]} {
> # do something
> }
> }
A commit without a change should not bump revision numbers.
If the embedded keywords change, it should be because something in the
file has changed.
(Except for merging, that's how it works in CVS -- and I suspect, RCS --
I would expect all post-CVS VCS to not break *that*, at least. )
> If key words are to be expanded, it's perhaps better to segregate them in
> a header included in all source: keywords.h. Then the diffs are true, the
> objects have the data strings, and the other source files remain true.
I think it depends on what you're expanding the keywords *for*.
If they're going to be your software's release string... hell, yes, put
that in a header file... and don't rely on the VCS to increment it!
Shoot, if you have a pretty fixed release cycle -- only approved
software releases are distributed -- I would suggest not relying on
VCS keyword expasion. If, howver, it's a more fluid environment,
where there's no strict control over who's running what... then
it's potentially useful.
> Given a choice between key words and accurate diffs (and I have been given
> that choice in the past), I'll always go with sacrosanct source.
I used to put /* $Log$ */ at the end of my source files. I don't do that
anymore. It didn't really help anything, other than encouraging everyone
to commit useful, readable, spelling-checked log messages.
Which is, come to think of it, not a bad thing at all.
--
"Made changes to stuff."
Stewart Stremler
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
