RFR: 7141675 Fix jcheck issues in .m sources

[Daniel D. Daugherty]

That will be a problem. If jcheck is changed in such a way that
an already committed changeset would be rejected, then it has
to be added to the whitelist. Otherwise, a fresh clone will fail
when jcheck processes the now offending changeset...

Yes, this implies that jcheck has a scaling problem. As more
changesets are added to a repo, the more work jcheck has to
do... eventually all compute cycles will be consumed by
jcheck... :-)

Dan


On 2/1/12 7:44 AM, Michael McMahon wrote:
> Yes, that could be a problem. I think they will have to be added to 
> the whitelist.
>
> - Michael
>
> On 01/02/12 13:32, Weijun Wang wrote:
>> I'm wondering if jcheck is updated to include these .m files, will it 
>> reject the old changesets where the .m files contain trailing 
>> whitespaces? Or, should those changesets be added into the whitelist?
>>
>> Thanks
>> Max
>>
>>
>> On 02/01/2012 08:25 PM, Anthony Petrov wrote:
>>> Hi Michael,
>>>
>>> The patch looks fine to me. It would be great to update jcheck as well
>>> so that the formatting requirements be enforced for further putbacks.
>>>
>>> -- 
>>> best regards,
>>> Anthony
>>>
>>> On 2/1/2012 3:56 PM, Michael McMahon wrote:
>>>> This change is just to fix some white-space/tab problems that crept 
>>>> into
>>>> some objective C files whose filename (extension .m) is not currently
>>>> known to jcheck.
>>>>
>>>> http://cr.openjdk.java.net/~michaelm/7141675/webrev.1/
>>>>
>>>> There is nothing to see in the webrev as white-space diferences are
>>>> ignored.
>>>> But the patch shows the actual changes.
>>>>
>>>> Thanks
>>>> Michael.
>