RFC: Removing $Id$

[Gedare Bloom]

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

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