RFR: 7141675 Fix jcheck issues in .m sources

[Weijun Wang]

Maybe each rule inside jcheck can have a startdate, only changsets after 
that need to be checked. Nobody will try to fake the date, right?

-Max

On 02/01/2012 11:17 PM, Daniel D. Daugherty wrote:
> 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.
>>