RFR(XS): 7901298: jcheck should check that every file ends with exactly one newline

Wed May 13 09:37:23 UTC 2015

On 13/05/15 08:35, Volker Simonis wrote:
> Ping...
>
> Can anybody please have a look at the new webrev?

I am not a Reviewer on this project, but I quickly skimmed the webrev 
and it seems ok.

> I think the proposed solution is not so bad :)

I agree. If we want to evolve jcheck in a manner that enables more 
strict checking, then such an approach seems reasonable.

-Chris.

> Thanks,
> Volker
>
>
> On Thu, May 7, 2015 at 5:12 PM, Volker Simonis <volker.simonis at gmail.com> wrote:
>> Thanks Chris,
>>
>> I think now I got it. You are suggesting to configure the new feature
>> in .jcheck/conf right?
>>
>> OK, so what about this new version:
>>
>> http://cr.openjdk.java.net/~simonis/webrevs/2015/7901298.v2/
>>
>> I've introduced a new attribute 'check_eof' in .jcheck/conf which
>> controls the behaviour of the new feature:
>>
>> # Test if we should check for a correct EOF (i.e. files end with
>> exatly one '\n')
>> # This behaviour is controlled by the 'check_eof' attribute in the conf file.
>> # -1 means to not check for EOF at all.
>> #  0 means to potentially check all the changes for a correct EOF.
>> #    any other positive number is interpreted as the revision number or change-
>> #    set ID from which on jcheck should start checking for a correct EOF.
>> # If the 'check_eof' attribute is missing, '-1' (i.e. no EOF check)
>> will be assumed.
>>
>> This way we can change jcheck and add the new EOF checking without
>> changing its behaviour on any existing, jcheck-enabled repositories.
>> Afterwards, any single repository can enable the EOF-checking from an
>> arbitrary changeset on-wards.
>>
>> What do you think,
>> Volker
>>
>>
>> On Thu, May 7, 2015 at 11:35 AM, Chris Hegarty <chris.hegarty at oracle.com> wrote:
>>> Volker,
>>>
>>> I cannot answer the questions about the operation of the mercurial server, others better positioned than I should do that, but if jcheck is to ever evolve in a manner like you are suggesting then a repository may need a way to indicate to jcheck what level of checks should be done for certain regions of its history. Say, the .jcheck/conf file in the repo had an entry with a value of a changeset from where jcheck would enable this “new” stricter checking. It would be opt in by the repo/project and could be configurable to its local history ( i.e. enable from this changeset hash onward ). Previous changsets would be checked as they are today.
>>>
>>> -Chris.
>>>
>>> On 7 May 2015, at 10:25, Volker Simonis <volker.simonis at gmail.com> wrote:
>>>
>>>> Hi Iris,
>>>>
>>>> can you please explain what you mean with "On push to a server, the
>>>> entire repository is checked for compliance to jcheck, not just the
>>>> pushed changesets". Is this really the case for every push - i.e. if I
>>>> push a change to lets say jdk9/dev/hotspot does this mean that jcheck
>>>> is really run on the revision range 0:tip? And if that's the case,
>>>> what's the reason for it? I don't understand what that should be good
>>>> for, because commited changes can not be changed anyway.
>>>>
>>>> I also doubt that 'hg jcheck --rev 0:tip' is really run on every push
>>>> simply because of performance reasons. When I push a change that's
>>>> usually a matter of seconds. But when I tested 'hg jcheck --rev 0:tip'
>>>> as I wrote in one of my previous mails that took more than 10 minutes
>>>> on the hotspot repository.
>>>>
>>>> So if it would turn out that 'hg jcheck --rev 0:tip' is only used in
>>>> special scenarios, would it be acceptable to use jcheck with a special
>>>> command line switch in these scenarios which turns the test for proper
>>>> EOF format off? I could add such a command line option if that would
>>>> make sense.
>>>>
>>>> But in my opinion, this new check only makes sense if it will be
>>>> enabled by default, otherwise nobody would use it.
>>>>
>>>> Regards,
>>>> Volker
>>>>
>>>>
>>>> On Wed, May 6, 2015 at 11:05 PM, Iris Clark <iris.clark at oracle.com> wrote:
>>>>> Hi, Magnus.
>>>>>
>>>>>> Is it really the case that there can be no changes to jcheck which do not make all existing changesets in all existing forests pass?  How on earth are we then ever going to be able to raise the bar for quality?
>>>>>
>>>>> Theoretically, I don't think that there's a problem with modifying jcheck to improve the quality of the code.  The issue is that as the tool is currently written and used, there is no migration path for a higher bar.  The provided patch does not include a solution to this problem.
>>>>>
>>>>> Thanks,
>>>>> iris
>>>>>
>>>>> -----Original Message-----
>>>>> From: Magnus Ihse Bursie
>>>>> Sent: Tuesday, May 05, 2015 2:54 PM
>>>>> To: Jonathan Gibbons; code-tools-dev at openjdk.java.net; hg-tools-dev at openjdk.java.net
>>>>> Subject: Re: RFR(XS): 7901298: jcheck should check that every file ends with exactly one newline
>>>>>
>>>>> On 2015-05-05 23:35, Jonathan Gibbons wrote:
>>>>>>
>>>>>> On 05/05/2015 02:31 PM, Magnus Ihse Bursie wrote:
>>>>>>> On 2015-02-13 12:01, Volker Simonis wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> could somebody please review and sponsor the following small change
>>>>>>>> which adds a test for exactly one newline at the and of a file to
>>>>>>>> check:
>>>>>>>>
>>>>>>>> http://cr.openjdk.java.net/~simonis/webrevs/2015/7901298/
>>>>>>>> https://bugs.openjdk.java.net/browse/CODETOOLS-7901298
>>>>>>>
>>>>>>> Found this mail again now, when I wondered why it was not already fixed.
>>>>>>>
>>>>>>> The fix looks good to me, and I wish it was already in place :-). I'm
>>>>>>> not a formal jcheck reviewer though. :(
>>>>>>>
>>>>>>> /Magnus
>>>>>>
>>>>>> Magnus,
>>>>>>
>>>>>> Please see the follow-up discussion on hg-tools-dev.
>>>>>> http://mail.openjdk.java.net/pipermail/hg-tools-dev/2015-April/thread.
>>>>>> html
>>>>>>
>>>>>
>>>>> Quoting that discussion:
>>>>>> Do all of the changesets (-r 0:tip) in all existing forests where
>>>>>> jcheck is enabled pass with this change?
>>>>>
>>>>> Is it really the case that there can be no changes to jcheck which do not  make all existing changesets in all existing forests pass? How on earth are we then ever going to be able to raise the bar for quality?
>>>>>
>>>>> /Magnus
>>>