RFC: Removing $Id$
joel.sherrill at OARcorp.com
Wed May 2 18:42:09 UTC 2012
On 5/2/2012 1:26 PM, Gedare Bloom wrote:
> A quick inspection shows there is also:
> // $Id$
> /* $Id$ */
I can see these.
> $Id$ showing up all by itself
> | $Id$
An assembly file?
> And $Id$ used as part of a macro c.f. ./cpukit/pppd/utils.c:#define RCSID "$Id$"
PPPD is a third party utility. We would have to be careful on that one.
Probably a time to run "remove white space and end of line" and
"convert multiple blanks into a single one" scripts.
> On Wed, May 2, 2012 at 2:06 PM, Joel Sherrill<joel.sherrill at oarcorp.com> wrote:
>> On 05/02/2012 12:44 PM, Ralf Corsepius wrote:
>>> On 05/02/2012 07:15 PM, Joel Sherrill wrote:
>>>> We apparently didn't reach an obvious consensus
>>>> on removing $Id$ from every file that originated
>>>> from RTEMS.
>>>> IMO it is time to remove this relic.
>>> I agree, that these $Id$ now are meaningless and can be removed.
>>>> Any objections.
>>> My remark from previous discussion still remains:
>>> Does git have a counterpart to $Id$, which can be used to identify the
>>> version of a file?
>> I couldn't find anything that either didn't devolve to a hash
>> and/or require something special on the client side. I didn't
>> think that having special plugins on the user side would be
>> We don't tend to use the Ids much in bug reporting discussions.
>> I don't know that they are as useful as they are something
>> we are used to having.
>> If someone's Google-foo turns up something, we can
>> certainly consider it. But it is a non-starter with git
>> from my research.
>> Ralf.. you are pretty good at this type of script. If you are
>> up for doing this and no one objects, it would be appreciated.
>> The only caveats I see if that files often have this pattern (1)
>> * $Id$
>> Or ...
>> * $Id$
>> * Some text
>> It may be necessary to crunch two comments lines into 1 after
>> removing the $Id$.
>> The other pattern is in configure.ac and Makefile.am files
>> which often only have a comment block which doesn't have
>> much other then the $Id$ in it. What makes sense to leave?
>> ## Process this file with autoconf to produce a configure script.
>> ## $Id$
>> What should that look like afterwards?
>> I think most, if not all assembly, follows the C style rules for
>> file headers so should be the same as C files.
>>>>  No changes to *BSD, httpd, rpc/xdr or other third party
>>>> originated code to be made.
>>> These files usually carry RTEMS-CVS $Id$ (modulo bugs), which should be
>>> subject to the same treatment as all other $Id$, but carry additional
>>> protected/special $Id$s, which had been necessary to protect them from
>>> RTEMS-CVS modifying these files' original $Id$s
>> Agreed for *BSD code. Each library would have to be examined
>> to ensure the proper rule to apply.
>> Joel Sherrill, Ph.D. Director of Research& Development
>> joel.sherrill at OARcorp.com On-Line Applications Research
>> Ask me about RTEMS: a free RTOS Huntsville AL 35805
>> Support Available (256) 722-9985
>> rtems-devel mailing list
>> rtems-devel at rtems.org
More information about the devel