RFR(XS): 7901298: jcheck should check that every file ends with exactly one newline
chris.hegarty at oracle.com
Thu May 7 09:35:42 UTC 2015
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.
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.
> 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.
>> -----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:
>>>>> 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
>>>> 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. :(
>>> Please see the follow-up discussion on hg-tools-dev.
>> 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?
More information about the hg-tools-dev