RFC: Removing $Id$

Joel Sherrill joel.sherrill at OARcorp.com
Thu May 3 12:56:30 UTC 2012


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. If we go down this
path, then release images should have "ignore" files which
work with cvs, svn, git, etc.

We made a conscious decision to not worry about code we
did not control.

Given that we are using git, they can easily set up
a private repository and track their changes against ours.
>
> 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.

Pavel Pisa suggested having a NEWS or CHANGES file that
only highlighted major changes. This minimizes conflicts
and presents the information people care about.

As an example of how things get lost, Gedare added
CONFIGURE_UNLIMITED_OBJECTS. From a user and
release perspective, that single commit needed to
be highlighted. This is the type of change that needs
to go in the 4.11 release notes page.

As another random aside, our log entries in general suck.
Anyone can look at the diff and see WHAT changed. The
log needs to say "WHY" and "WHAT IT FIXED".
>> 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)
> 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.
That's fine. I will nibble on it and you can pitch in when
you can.
> 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





More information about the devel mailing list