RFR: 7141675 Fix jcheck issues in .m sources
Daniel D. Daugherty
daniel.daugherty at oracle.com
Wed Feb 1 07:17:46 PST 2012
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
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?
>> 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,
>>> On 2/1/2012 3:56 PM, Michael McMahon wrote:
>>>> This change is just to fix some white-space/tab problems that crept
>>>> some objective C files whose filename (extension .m) is not currently
>>>> known to jcheck.
>>>> There is nothing to see in the webrev as white-space diferences are
>>>> But the patch shows the actual changes.
More information about the macosx-port-dev