Bug 4157 - Add RCS keyword $Header$ to all files to support development
Add RCS keyword $Header$ to all files to support development
Product: rsync
Classification: Unclassified
Component: core
All All
: P3 enhancement
: ---
Assigned To: Wayne Davison
Rsync QA Contact
Depends on:
  Show dependency treegraph
Reported: 2006-10-09 17:07 UTC by hoffa
Modified: 2006-10-11 07:15 UTC (History)
0 users

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description hoffa 2006-10-09 17:07:09 UTC
Add RCS keyword $Header$ to all files to support development.

It would be great to have this added to _all_ the RCS/cvs controlled
files. Many sites/developers manage piles of files/patches, work to
bring them to the recent HEAD/release for submission and so on. Having
these strings present helps to identify the initial source rev of the
file and later on when distilling diffs it can be very useful.  It can
be hard at times to figure out what the initial source rev for a file
was if the file doesn't contain that info and the user adapting the
file/patch is not the author [who might erroneously be expected to
know/remember:-] said info.

# Before
cvs diff -u will show the checked out revnum in the diff header.
However if using raw files as the work base, without cvs, the file and
all subsequent edits are devoid of original version info.  There is no
reference against which to do a cvs diff -ur <rev> if cvs is later
adopted, etc. Especially if the history of the file is not known to
the user.

# Enhancement
Add this literal at some consistent place near the top of all the
files, escape it if needed with the normal conventions.
 Add either:  $Header$  or  $Id$
 Typical escapes:  # $Header$  ,  /* $Header$ */  ,  etc
Cvs commit, enjoy the benefits.

# After
Now it's easier to bring random files/patches in line with cvs.
$Header: /.../foo,v 1.1 2006/10/09 20:50:41 user Exp $
$Id: foo,v 1.1 2006/10/09 20:50:41 user Exp $

Full documentation for this is at:

This could probably be scripted as a one time commit.
find -E . -type f \! -regex '^.*/CVS/.*$' -print0 | xargs -0 ed ...

Comment 1 hoffa 2006-10-09 19:38:56 UTC
Just checked, all the files in HEAD are free from conflict
with $Header$/$Id$ except for 9 files under zlib which
are expansion blocked with cvs admin -ko/-kb in the rcs file.
11 more zlib files are blocked but there is no corresponding
keyword in the HEAD file to block. ie: inffixed.h. So the block
could be removed where not in conflct with the current or
imported zlib. With imported sources, it can also be useful to
not admin block expansion in RCS instead, preserve and disable
by remove the $'s in the Header/Id line before import, then add
the local $Header$/$Id$ which will expand as usual. Using
export -kv will do this if the RCS of the import is available.

Ref: cvs(1), co(1), ident(1).

Note also the use of /usr/bin/ident against files having
been compiled with this or similar code:
 static char *id="$Id$";

The ident syntax is also free except for the trival case of:
./patches/acls.diff:+           char            *id     = "";

Comment 2 Wayne Davison 2006-10-10 19:09:54 UTC
Sorry, I don't like magic strings inside source files.  In particular, I don't want a commit to cause a file to change.
Comment 3 hoffa 2006-10-11 07:15:12 UTC
Hmm, I'm confused. Not to contest but perhaps fill in more info.
A checked out file can normally only be committed if indeed, by
definition, the user has intentionally changed its contents
on purpose. The revision number bump should be expected in that
case and is only bumped for the files committed, not the whole
repo. The magic is only magic to cvs and ignored by others when
commented out in their usual syntax of C, sh, perl, etc. cvs diff
knows not to print the Id which would otherwise litter diffs with
superfluous chatter. It's mostly set and forget. The ident *char
can be omitted if the trivial const added to compiled code would
be untenable.

Are other massive projects such as FreeBSD, NetBSD, OpenBSD,
Xorg, XFree86, browsers, apps, etc that are currently using
Id everywhere experience issues. How could user easily match
a discovered source file/patch to its corresponding base
revision to work from.

Whatever works, food for thought, /user defers.