Roland Mainz wrote:
> Garrett D'Amore wrote:
>
>> Roland Mainz wrote:
>>
>>> Garrett D'Amore wrote:
>>>
>>>> Alan Coopersmith wrote:
>>>>
>>>>> Roland Mainz wrote:
>>>>>
>>>>>> As said I can remove them for the Makefiles+code we "own" now and the
>>>>>> others as late as possible since the "ident" stuff is the _major_ source
>>>>>> of bitrot. I don't want to play the "catch the ident changes"-game over
>>>>>> and over again since the time for that comes from my almost non-existing
>>>>>> chunk of free time...
>>>>>>
>>>>> Are you saying the ident lines in question are in the upstream source, not
>>>>> Sun added? If so, then leaving them in permanently and having the ON CRT
>>>>> waive their removal is the only sane choice. Upstream code should always
>>>>> be exempt from style and formatting rules such as ident removal and
>>>>> cstyle,
>>>>> since otherwise every update is an exercise in pointless time wasting.
>>>>>
>>>>>
>>>> Agreed, *IF* the ident keywords are *expanded* (as they should be in
>>>> this case). If they are not expanded with SCCS, then they can
>>>> potentially do more harm then good.
>>>>
>>> See my reply - we don't have "ident" lines in the AST codebase.
>>>
>> So, then why do we have them *anywhere*. There shouldn't be "bitrot".
>> You should purge them all once, and be done with it. Or am I badly
>> misunderstanding something here?
>>
>
> The issue is that the rules (AFAIK) require to remove the "ident" lines
> from all files we "touch". Since we have lots of changes in
> usr/src/pkgdefs/, Makefile.master and other parts we run into collisions
> when other people remove the "ident" lines before we do it. That was the
> major pain when merging the changes from the B84-based prototype011 to
> the Mercurial/HEAD-based prototype012 - all the changes to update the
> license template, the copyright year and ident lines caused massive
> bitrot and since "merge" is stupid any lines near these changes were
> rejected, too. Half a night was wasted with the merge, verification and
> testing... and I am not keen to do that again until we do the final
> putback. And I would even prefer to do this as a seperate putback (to
> avoid that this makes our 4.5MB monster patch even bigger) since this
> would save _lots_ of time on my side.
>
Ah, now I understand.
This is the pain you suffer because you're going in very soon after the
post-Hg conversion.
Personally, I think you need to bite the bullet on it. Over time, the
number of Makefiles, packaging files, etc. that you have to merge this
change against should *quickly* diminish. Its not like the #ident line
is changing constantly -- its more a case of the "first one in is
obliged to remove it". If you've already bitten the bullet on some
files, you shouldn't need to churn on those files again. (At least not
because of ident lines, anyway.)
Anyway, you won't be permitted to submit your RTI (or rather your RTI
advocate won't accept the RTI) until you can demonstrate hg nits/pbchk
clean (modulo any waivers you've received). Most likely this means
while you can wait a little while, you *will* need to do the merge some
hours before you finally get permission to do the push.
No matter what happens, you *will* have to do a full merge against ON
before you push. Its better to do that somewhat frequently as you near
completion, IMO, since it reduces the risk of having a scary change go
by unnoticed in a large set of changes. (Smaller merges are easier.)
I also disabled premerge in my hgrc, so that hg doensn't "silently"
clobber/corrupt my files as a result of a mismerge. (Automatic merge
without human oversight *scares* me. I've seen it go wrong too many
times to trust it.)
- Garrett
> ----
>
> Bye,
> Roland
>
>
