[PATCH] Properly (.hg)ignore the JTwork and JTreport directories

[David Holmes]

Hi Gustavo,

On 1/07/2019 11:44 pm, Gustavo Romero wrote:
> Hi Jaikiran, David
> 
> On 06/30/2019 10:55 PM, Jaikiran Pai wrote:
>>
>> On 01/07/19 4:00 AM, David Holmes wrote:
>>> On 30/06/2019 10:22 pm, Jaikiran Pai wrote:
>>>> Hello David,
>>>>
>>>> On 30/06/19 11:03 AM, David Holmes wrote:
>>>>> Hi Jaikiran,
>>>>>
>>>>> On 29/06/2019 5:16 am, Jaikiran Pai wrote:
>>>>>> Can I please get a review and a sponsor for this patch[1] which fixes
>>>>>> the .hgignore file to take into account the JTreport and JTwork
>>>>>> directories that can reside at the root of the repository.
>>>>>
>>>>> I don't see any problem with current settings. I wonder if it is hg
>>>>> version specific?
>>>>>
>>>> That's possible. I am on macOS (10.14.1) with mercurial version at
>>>> 4.3.1:
>>>>
>>>> hg --version
>>>> Mercurial Distributed SCM (version 4.3.1)
>>>> (see https://mercurial-scm.org for more information)
>>>>
>>>> I will upgrade to latest release of mercurial and see if it changes
>>>> anything.
>>>
>>> I'm actually downrev at 3.4.2, on Linux.
>>>
>>> David
>>
>> I upgraded to 5.0.1:
>>
>> hg --version
>> Mercurial Distributed SCM (version 5.0.1)
>> (see https://mercurial-scm.org for more information)
>>
>> and haven't seen a difference. The JTwork and JTreport at the root of
>> the repos still aren't ignored.
> 
> Jaikiran, thanks for enhancing the .hgignore.
> 
> I do would like to extend the reachout of .hgignore for JT*, specially 
> for the
> root dir, because when fixing some jtreg tests, for instance, it's 
> common one to
> trigger jtreg from the root for specific tests being fixed and so a 
> JTwork and
> JTreport will be created. The currently ignore rules won't cover that so I
> think your enhancement is welcome.

What version of hg are you using?

I don't mind making changes but if hg is changing the way it processes 
this file across different versions then we need to be sure that this is 
working for all of them.

I'm also not sure jdk-dev is the right mailing list here as there may be 
few people actively watching for patches here.

Thanks,
David
-----

> I don't think the glob syntax is needed, so I'm wondering why not use 
> simply
> something like:
> 
> --- a/.hgignore Tue May 07 09:37:02 2019 -0700
> +++ b/.hgignore Mon Jul 01 09:48:04 2019 -0300
> @@ -11,6 +11,8 @@
>   test/nashorn/script/external
>   test/nashorn/lib
>   NashornProfile.txt
> -.*/JTreport/.*
> -.*/JTwork/.*
> +.*JTreport/.*
> +.*JTwork/.*
> 
> I would like to ignore too the hsdis/build since it's also common to 
> build hsdis
> for debugging purposes and hsdis/Makefile relies on ./build/binutils 
> already, so
> the "build" dir is not arbitrary in fact.
> 
> I'm wondering also if it's ok for the community to add "oprofile_data" 
> also to
> the list to ignore Oprofile data files,  like:
> 
> --- a/.hgignore Tue May 07 09:37:02 2019 -0700
> +++ b/.hgignore Mon Jul 01 10:38:26 2019 -0300
> @@ -11,6 +11,8 @@
>   test/nashorn/script/external
>   test/nashorn/lib
>   NashornProfile.txt
> -.*/JTreport/.*
> -.*/JTwork/.*
> +.*JTreport/.*
> +.*JTwork/.*
>   .*/.git/.*
> +^src/utils/hsdis/build
> +.*oprofile_data/
> 
> But Feel free to leave hsdis and oprofile_data out for now if you wish 
> or deal
> with it after you get more reviews and comments on your change.
> 
> You need to create a JBS entry even for simple changes like that one and 
> send a
> formal RFR to the build-dev ML (please see an example below, in [0]). 
> Format
> should be:
> 
> RFR(estimated effort to review / change size): <bugid>: <title>
> 
> I'm not a Reviewer, so you'll need 2 Reviews from Reviewers. If the 
> change is
> considered trivial, only one Review is sufficient to get it approved. 
> You can
> always check for the JDK Reviewers in [1].
> 
> I see you signed the OCA [2], so I can sponsor your change once it's 
> Reviewed.
> 
> Best regards,
> Gustavo
> 
> [0] https://mail.openjdk.java.net/pipermail/build-dev/2018-May/022019.html
> [1] https://openjdk.java.net/census#jdk
> [2] https://www.oracle.com/technetwork/community/oca-486395.html#p