RFC: Removing $Id$

[Joel Sherrill]

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