RFC: Removing $Id$

Ralf Corsepius ralf.corsepius at rtems.org
Thu May 3 15:09:43 UTC 2012

On 05/03/2012 02:56 PM, Joel Sherrill wrote:
> On 05/03/2012 03:39 AM, Ralf Corsepius wrote:
>> On 05/02/2012 08:06 PM, Joel Sherrill 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.
>> Well, but you do care about the BSD-Id's in RTEMS?
>> For external parties, who import RTEMS into their own VCS, the RTEMS
>> Id's play a similar role as do the BSD-Ids for us.
> We have had similar discussions in the past.
Yes, and my position has not changed.

CVS $Id$ have their uses and have been ditched by the move to git.

> If we go down this
> path, then release images should have "ignore" files which
> work with cvs, svn, git, etc.
Absolutely no.

Released sources (tarballs) must be independent of the VCS in use but 
must provide sufficient meta-information to keep them long term 
(measured in decades) maintainable.

CVS had supplied $Id$ as its means to provide such meta-information. 
With git, we currently have nothing comparable.

>> This is the more important as RTEMS doesn't provide proper ChangeLogs
>> anymore, which play a similar role when comparing source-trees outside
>> of a VCS (e.g. when comparing tarballs).
> That's the next issue.
> These need to be renamed.  I think it
> was Thomas who suggested just renaming them
> ChangeLog-pre2012.
This is a non-important side-issue.

The real issue is RTEMS not providing _any_ ChangeLogs for current and 
on-going changes.

> Pavel Pisa suggested having a NEWS or CHANGES file that
> only highlighted major changes.
That's another, widely unimportant side-issue.
> This minimizes conflicts
> and presents the information people care about.
Well, there are not more conflicts than they used to be with CVS.

>>> 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)
>> I'll see what I can do, but these days, I am busy with topics outside of
>> RTEMS and will hardly be able to find a free time-slot.
> Ralf.. you are pretty good at this type of script. If you are
> That's fine. I will nibble on it and you can pitch in when
> you can.
Please don't "nibble too much", otherwise it'll be hard to generalize 
patterns to eliminate.
(Background: I usually use sed or perl patterns to filter. When you 
manually "nibble" $Id$, it will be difficult to filterout the 
surrounding comments and empty lines).


More information about the devel mailing list