Removing $Id$

Joel Sherrill joel.sherrill at OARcorp.com
Thu May 3 13:39:18 UTC 2012


HI

I have hacked together a sed script which I think will
handle almost all of the source code. I think it handles
enough to catch nearly all of the source files

+ $Id$ embedded in C comment
    - handles $Id followed or preceded by line with " *"
+ C++ style $Id$
+ Single line C style comment with $Id$
+ $Id$ embedded in Ada comment
    - handles $Id followed or preceded by line with "--"
+ $Id$ embedded in Texinfo comment
    - only preceded by @c since that appears to be only use

I do not know what to do with *.am, *.ac, *.m4 etc which start
with something like this and have no meat in the comments.

====
<comment_symbol>
<comment_symbol> $Id$
<comment_symbol>

====

<comment_symbol> may be #, ##, or dnl from what I
see

Since there is no meat to these comments. I am prone to delete
the four line block entirely.

Comments?

--joel

On 05/02/2012 05:57 PM, Joel Sherrill wrote:
> On 05/02/2012 01:59 PM, Gedare Bloom wrote:
>> On Wed, May 2, 2012 at 2:42 PM, Joel Sherrill<joel.sherrill at oarcorp.com>   wrote:
>>> 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?
>>>
>> ./c/src/libchip/display/disp_hcms29xx.c:|  $Id$
>> ./c/src/libchip/display/font_hcms29xx.c:|  $Id$
>> ./c/src/lib/libbsp/i386/pc386/timer/timerisr.S:|  $Id$
>> ./c/src/lib/libbsp/i386/pc386/startup/ldsegs.S:|  $Id$
> I found and fixed all of this pattern. There were more
> in different files.
>> I also found:
>> ./c/src/lib/libbsp/sparc/leon3/startup/bspdelay.c: *  $Id
>> ./c/src/lib/libbsp/sparc/leon2/startup/bspdelay.c: *  $Id
>> ./c/src/lib/libbsp/m68k/mrm332/startup/start_c.c: *  $Id
> Committing a fix for these.
>
> Along with a fix for those with $Id: and nothing following.
>
> FWIW my fix involved removing them and splitting the
> copyright notice into a separate comment block.
>>>> 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.
>>>
>> That one repeats a few times in pppd.
>>
>>> Probably a time to run "remove white space and end of line" and
>>> "convert multiple blanks into a single one" scripts.
>>>
>>>> -Gedare
>>>>
>>>> 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:
>>>>>>> Hi
>>>>>>>
>>>>>>> We apparently didn't reach an obvious consensus
>>>>>>> on removing $Id$ from every file that originated
>>>>>>> from RTEMS.[1]
>>>>>>>
>>>>>>> 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
>>>>> desirable.
>>>>>
>>>>> 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.
>>>>>
>>>>>>> [1] 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.
>>>>>> Ralf
>>>>>>
>>>>>>
>>>>> --
>>>>> 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
>>>>> http://www.rtems.org/mailman/listinfo/rtems-devel
>


-- 
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





More information about the devel mailing list