From attila.szegedi at oracle.com Fri Sep 11 12:41:14 2015
From: attila.szegedi at oracle.com (Attila Szegedi)
Date: Fri, 11 Sep 2015 14:41:14 +0200
Subject: webrev.ksh inserts full commit history of a file
Message-ID: <239E96B1-7CDE-4ED1-8799-EC41F1ECEE1A@oracle.com>
Recently I noticed webrev.ksh started including the full commit history of files into the generated webrevs. E.g. see http://cr.openjdk.java.net/~attila/8135262/webrev.jdk9/
I have seen some other people recently posting webrevs suffering from the same problem, e.g. >
One thing I did recently was reinstall all my MacPorts as part of upgrading them for OS X 10.10, so my ports-provided Mercurial now identifies itself as ?3.4.99? in port list and as ?3.5-rc+12-a74e9806d17d? with ?hg ?version?. Not sure if that matters. If anybody has an insight into it, please let me know.
Thanks,
Attila.
From daniel.fuchs at oracle.com Sat Sep 12 18:09:34 2015
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Sat, 12 Sep 2015 20:09:34 +0200
Subject: webrev.ksh inserts full commit history of a file
In-Reply-To: <239E96B1-7CDE-4ED1-8799-EC41F1ECEE1A@oracle.com>
References: <239E96B1-7CDE-4ED1-8799-EC41F1ECEE1A@oracle.com>
Message-ID: <55F46A5E.4000106@oracle.com>
Hi Attila,
Could you compare the revision listed in the webrev with what hg outgoing
reports (and could you tell us which options you were using when calling
webrev)?
best regards,
-- daniel
On 9/11/15 2:41 PM, Attila Szegedi wrote:
> Recently I noticed webrev.ksh started including the full commit history of files into the generated webrevs. E.g. see http://cr.openjdk.java.net/~attila/8135262/webrev.jdk9/
>
> I have seen some other people recently posting webrevs suffering from the same problem, e.g. >
>
> One thing I did recently was reinstall all my MacPorts as part of upgrading them for OS X 10.10, so my ports-provided Mercurial now identifies itself as ?3.4.99? in port list and as ?3.5-rc+12-a74e9806d17d? with ?hg ?version?. Not sure if that matters. If anybody has an insight into it, please let me know.
>
> Thanks,
> Attila.
>
>
>
>
From volker.simonis at gmail.com Mon Sep 14 07:24:53 2015
From: volker.simonis at gmail.com (Volker Simonis)
Date: Mon, 14 Sep 2015 09:24:53 +0200
Subject: webrev.ksh inserts full commit history of a file
In-Reply-To: <239E96B1-7CDE-4ED1-8799-EC41F1ECEE1A@oracle.com>
References: <239E96B1-7CDE-4ED1-8799-EC41F1ECEE1A@oracle.com>
Message-ID:
Hi Attila,
you can use '-r rev' to compare against a specific revision. I use it
together with Mercurial Queues if I have changes from my queue pushed
but only want a webrev of the top-most change. In that case I do
"webrev.ksh -r qbase".
Also you can use '-N' to prevent webrev.ksh doing 'hg outgoing' and
instead producing a webrev of local changes only (i.e. 'hg status').
Regards,
Volker
On Fri, Sep 11, 2015 at 2:41 PM, Attila Szegedi
wrote:
> Recently I noticed webrev.ksh started including the full commit history of files into the generated webrevs. E.g. see http://cr.openjdk.java.net/~attila/8135262/webrev.jdk9/
>
> I have seen some other people recently posting webrevs suffering from the same problem, e.g. >
>
> One thing I did recently was reinstall all my MacPorts as part of upgrading them for OS X 10.10, so my ports-provided Mercurial now identifies itself as ?3.4.99? in port list and as ?3.5-rc+12-a74e9806d17d? with ?hg ?version?. Not sure if that matters. If anybody has an insight into it, please let me know.
>
> Thanks,
> Attila.
>
>
>
>
From attila.szegedi at oracle.com Tue Sep 15 11:32:48 2015
From: attila.szegedi at oracle.com (Attila Szegedi)
Date: Tue, 15 Sep 2015 13:32:48 +0200
Subject: webrev.ksh inserts full commit history of a file
In-Reply-To:
References: <239E96B1-7CDE-4ED1-8799-EC41F1ECEE1A@oracle.com>
Message-ID:
I knew about -r and have used it in the past; unfortunately it didn?t help. Even doing ?webrev.ksh -N -r qparent? gives me the wrong results (still a full commit history).
Attila.
> On Sep 14, 2015, at 9:24 AM, Volker Simonis wrote:
>
> Hi Attila,
>
> you can use '-r rev' to compare against a specific revision. I use it
> together with Mercurial Queues if I have changes from my queue pushed
> but only want a webrev of the top-most change. In that case I do
> "webrev.ksh -r qbase".
>
> Also you can use '-N' to prevent webrev.ksh doing 'hg outgoing' and
> instead producing a webrev of local changes only (i.e. 'hg status').
>
> Regards,
> Volker
>
>
> On Fri, Sep 11, 2015 at 2:41 PM, Attila Szegedi
> wrote:
>> Recently I noticed webrev.ksh started including the full commit history of files into the generated webrevs. E.g. see http://cr.openjdk.java.net/~attila/8135262/webrev.jdk9/
>>
>> I have seen some other people recently posting webrevs suffering from the same problem, e.g. >
>>
>> One thing I did recently was reinstall all my MacPorts as part of upgrading them for OS X 10.10, so my ports-provided Mercurial now identifies itself as ?3.4.99? in port list and as ?3.5-rc+12-a74e9806d17d? with ?hg ?version?. Not sure if that matters. If anybody has an insight into it, please let me know.
>>
>> Thanks,
>> Attila.
>>
>>
>>
>>
From volker.simonis at gmail.com Tue Sep 15 12:47:29 2015
From: volker.simonis at gmail.com (Volker Simonis)
Date: Tue, 15 Sep 2015 14:47:29 +0200
Subject: webrev.ksh inserts full commit history of a file
In-Reply-To:
References: <239E96B1-7CDE-4ED1-8799-EC41F1ECEE1A@oracle.com>
Message-ID:
The thing I noticed in your bad examples is that in the you compare
against "ssh://hg.openjdk.java.net/jdk9/dev/nashorn". I'm not sure if
this is a problem (or maybe only a problem if you are sitting behind a
firewall). I don't have 'default-push' defined in my .hg/hgrc files so
webrev.ksh is always using the 'default' entry (which is a http-URL)
and I never saw these problems. Webrev.ksh first reads 'default-push'
and only if this isn't defined it reads the 'default' path. Maybe you
can give it a quick try and use "-p http://hg.open..." to see if this
helps?
Also, which version of webrev.ksh are you using, the latest one?
On Tue, Sep 15, 2015 at 1:32 PM, Attila Szegedi
wrote:
> I knew about -r and have used it in the past; unfortunately it didn?t help. Even doing ?webrev.ksh -N -r qparent? gives me the wrong results (still a full commit history).
>
> Attila.
>
>> On Sep 14, 2015, at 9:24 AM, Volker Simonis wrote:
>>
>> Hi Attila,
>>
>> you can use '-r rev' to compare against a specific revision. I use it
>> together with Mercurial Queues if I have changes from my queue pushed
>> but only want a webrev of the top-most change. In that case I do
>> "webrev.ksh -r qbase".
>>
>> Also you can use '-N' to prevent webrev.ksh doing 'hg outgoing' and
>> instead producing a webrev of local changes only (i.e. 'hg status').
>>
>> Regards,
>> Volker
>>
>>
>> On Fri, Sep 11, 2015 at 2:41 PM, Attila Szegedi
>> wrote:
>>> Recently I noticed webrev.ksh started including the full commit history of files into the generated webrevs. E.g. see http://cr.openjdk.java.net/~attila/8135262/webrev.jdk9/
>>>
>>> I have seen some other people recently posting webrevs suffering from the same problem, e.g. >
>>>
>>> One thing I did recently was reinstall all my MacPorts as part of upgrading them for OS X 10.10, so my ports-provided Mercurial now identifies itself as ?3.4.99? in port list and as ?3.5-rc+12-a74e9806d17d? with ?hg ?version?. Not sure if that matters. If anybody has an insight into it, please let me know.
>>>
>>> Thanks,
>>> Attila.
>>>
>>>
>>>
>>>
>
From attila.szegedi at oracle.com Tue Sep 15 13:59:38 2015
From: attila.szegedi at oracle.com (Attila Szegedi)
Date: Tue, 15 Sep 2015 15:59:38 +0200
Subject: webrev.ksh inserts full commit history of a file
In-Reply-To:
References: <239E96B1-7CDE-4ED1-8799-EC41F1ECEE1A@oracle.com>
Message-ID: <40110C36-8BE1-4987-9A16-16C507F4DACF@oracle.com>
Thanks both Volker and Daniel for responding.
Apparently, the --follow option is causing the trouble (as used in `hg log ?` command within the comments_from_mercurial() function. I forced webrev to print how it invokes hg, and it was sending it e.g.:
hg log --rev 1507 --rev 1508 --follow --template 'rev {rev} : {desc}\n' src/jdk/nashorn/internal/codegen/AssignSymbols.java
And this indeed creates the full history. If I remove ?--follow? from the command line, I get the expected output. I now have Mercurial 3.5.1 (yep, I know, bleeding edge?). For now, I just removed ?--follow? from my local copy of webrev.ksh, this seems like it?ll do for me.
Thanks to everyone who offered to help!
Attila.
> On Sep 15, 2015, at 2:47 PM, Volker Simonis wrote:
>
> The thing I noticed in your bad examples is that in the you compare
> against "ssh://hg.openjdk.java.net/jdk9/dev/nashorn". I'm not sure if
> this is a problem (or maybe only a problem if you are sitting behind a
> firewall). I don't have 'default-push' defined in my .hg/hgrc files so
> webrev.ksh is always using the 'default' entry (which is a http-URL)
> and I never saw these problems. Webrev.ksh first reads 'default-push'
> and only if this isn't defined it reads the 'default' path. Maybe you
> can give it a quick try and use "-p http://hg.open..." to see if this
> helps?
>
> Also, which version of webrev.ksh are you using, the latest one?
>
> On Tue, Sep 15, 2015 at 1:32 PM, Attila Szegedi
> wrote:
>> I knew about -r and have used it in the past; unfortunately it didn?t help. Even doing ?webrev.ksh -N -r qparent? gives me the wrong results (still a full commit history).
>>
>> Attila.
>>
>>> On Sep 14, 2015, at 9:24 AM, Volker Simonis wrote:
>>>
>>> Hi Attila,
>>>
>>> you can use '-r rev' to compare against a specific revision. I use it
>>> together with Mercurial Queues if I have changes from my queue pushed
>>> but only want a webrev of the top-most change. In that case I do
>>> "webrev.ksh -r qbase".
>>>
>>> Also you can use '-N' to prevent webrev.ksh doing 'hg outgoing' and
>>> instead producing a webrev of local changes only (i.e. 'hg status').
>>>
>>> Regards,
>>> Volker
>>>
>>>
>>> On Fri, Sep 11, 2015 at 2:41 PM, Attila Szegedi
>>> wrote:
>>>> Recently I noticed webrev.ksh started including the full commit history of files into the generated webrevs. E.g. see http://cr.openjdk.java.net/~attila/8135262/webrev.jdk9/
>>>>
>>>> I have seen some other people recently posting webrevs suffering from the same problem, e.g. >
>>>>
>>>> One thing I did recently was reinstall all my MacPorts as part of upgrading them for OS X 10.10, so my ports-provided Mercurial now identifies itself as ?3.4.99? in port list and as ?3.5-rc+12-a74e9806d17d? with ?hg ?version?. Not sure if that matters. If anybody has an insight into it, please let me know.
>>>>
>>>> Thanks,
>>>> Attila.
>>>>
>>>>
>>>>
>>>>
>>
From volker.simonis at gmail.com Wed Sep 16 17:18:59 2015
From: volker.simonis at gmail.com (Volker Simonis)
Date: Wed, 16 Sep 2015 19:18:59 +0200
Subject: RFR(XS): 7901508: JTreg with '-noshell' wrongly exectes shell tests
with an implicit 'run shell' action
Message-ID:
Hi,
could somebody please review and sponsor this small fix:
http://cr.openjdk.java.net/~simonis/webrevs/2015/7901508/
https://bugs.openjdk.java.net/browse/CODETOOLS-7901508
The '-noshell' command line option should instruct JTreg to not
execute tests which contain shell actions. Unfortunately this option
is broken for shell tests which do not explicitly specify a run action
with '@run shell ...'.
Notice that specifying a run action is not necessary because the
default for '.sh' files is '@run shell ' anyway. There exist
plenty of shell tests which do not specify the run action explicitly.
The problem is that the pattern which checks for the run action
wrongly assumes that the action can only be user-specified.
Thank you and best regards,
Volker
From volker.simonis at gmail.com Wed Sep 16 17:29:43 2015
From: volker.simonis at gmail.com (Volker Simonis)
Date: Wed, 16 Sep 2015 19:29:43 +0200
Subject: webrev.ksh inserts full commit history of a file
In-Reply-To: <40110C36-8BE1-4987-9A16-16C507F4DACF@oracle.com>
References: <239E96B1-7CDE-4ED1-8799-EC41F1ECEE1A@oracle.com>
<40110C36-8BE1-4987-9A16-16C507F4DACF@oracle.com>
Message-ID:
Just for reference: the following bug already exists for this misbehaviour:
Mercurial 3.4 breaks behavior of webrev -r
https://bugs.openjdk.java.net/browse/CODETOOLS-7901466
On Tue, Sep 15, 2015 at 3:59 PM, Attila Szegedi
wrote:
> Thanks both Volker and Daniel for responding.
>
> Apparently, the --follow option is causing the trouble (as used in `hg log ?` command within the comments_from_mercurial() function. I forced webrev to print how it invokes hg, and it was sending it e.g.:
>
> hg log --rev 1507 --rev 1508 --follow --template 'rev {rev} : {desc}\n' src/jdk/nashorn/internal/codegen/AssignSymbols.java
>
> And this indeed creates the full history. If I remove ?--follow? from the command line, I get the expected output. I now have Mercurial 3.5.1 (yep, I know, bleeding edge?). For now, I just removed ?--follow? from my local copy of webrev.ksh, this seems like it?ll do for me.
>
> Thanks to everyone who offered to help!
>
> Attila.
>
>> On Sep 15, 2015, at 2:47 PM, Volker Simonis wrote:
>>
>> The thing I noticed in your bad examples is that in the you compare
>> against "ssh://hg.openjdk.java.net/jdk9/dev/nashorn". I'm not sure if
>> this is a problem (or maybe only a problem if you are sitting behind a
>> firewall). I don't have 'default-push' defined in my .hg/hgrc files so
>> webrev.ksh is always using the 'default' entry (which is a http-URL)
>> and I never saw these problems. Webrev.ksh first reads 'default-push'
>> and only if this isn't defined it reads the 'default' path. Maybe you
>> can give it a quick try and use "-p http://hg.open..." to see if this
>> helps?
>>
>> Also, which version of webrev.ksh are you using, the latest one?
>>
>> On Tue, Sep 15, 2015 at 1:32 PM, Attila Szegedi
>> wrote:
>>> I knew about -r and have used it in the past; unfortunately it didn?t help. Even doing ?webrev.ksh -N -r qparent? gives me the wrong results (still a full commit history).
>>>
>>> Attila.
>>>
>>>> On Sep 14, 2015, at 9:24 AM, Volker Simonis wrote:
>>>>
>>>> Hi Attila,
>>>>
>>>> you can use '-r rev' to compare against a specific revision. I use it
>>>> together with Mercurial Queues if I have changes from my queue pushed
>>>> but only want a webrev of the top-most change. In that case I do
>>>> "webrev.ksh -r qbase".
>>>>
>>>> Also you can use '-N' to prevent webrev.ksh doing 'hg outgoing' and
>>>> instead producing a webrev of local changes only (i.e. 'hg status').
>>>>
>>>> Regards,
>>>> Volker
>>>>
>>>>
>>>> On Fri, Sep 11, 2015 at 2:41 PM, Attila Szegedi
>>>> wrote:
>>>>> Recently I noticed webrev.ksh started including the full commit history of files into the generated webrevs. E.g. see http://cr.openjdk.java.net/~attila/8135262/webrev.jdk9/
>>>>>
>>>>> I have seen some other people recently posting webrevs suffering from the same problem, e.g. >
>>>>>
>>>>> One thing I did recently was reinstall all my MacPorts as part of upgrading them for OS X 10.10, so my ports-provided Mercurial now identifies itself as ?3.4.99? in port list and as ?3.5-rc+12-a74e9806d17d? with ?hg ?version?. Not sure if that matters. If anybody has an insight into it, please let me know.
>>>>>
>>>>> Thanks,
>>>>> Attila.
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>
From volker.simonis at gmail.com Wed Sep 16 17:43:15 2015
From: volker.simonis at gmail.com (Volker Simonis)
Date: Wed, 16 Sep 2015 19:43:15 +0200
Subject: RFR(XXS): 7901509: Adjust bug title matching pattern after the
bugsystem changed the title format
Message-ID:
Hi,
can somebody please review and sponsor this tiny fix:
http://cr.openjdk.java.net/~simonis/webrevs/2015/7901509/
https://bugs.openjdk.java.net/browse/CODETOOLS-7901509
After the last update of JIRA the Java Bug systems returns a title
with no hash before t he bug ID:
[JDK-8062493] JEP 243: Java-Level JVM Compiler Interface - Java
Bug System
The pattern which parses the bug ID and Bug summary in webrev has to
be updated to accommodate for this change:
sed 's/\[\(.*\)\] \(.*\) - Java Bug System<\/title>/\1 : \2/'
vs the old:
sed 's/\[#\(.*\)\] \(.*\) - Java Bug System<\/title>/\1 : \2/'
Thank you and best regards,
Volker
From magnus.ihse.bursie at oracle.com Thu Sep 17 08:35:52 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Thu, 17 Sep 2015 10:35:52 +0200
Subject: RFR(XXS): 7901509: Adjust bug title matching pattern after the
bugsystem changed the title format
In-Reply-To:
References:
Message-ID: <55FA7B68.2010807@oracle.com>
On 2015-09-16 19:43, Volker Simonis wrote:
> Hi,
>
> can somebody please review and sponsor this tiny fix:
>
> http://cr.openjdk.java.net/~simonis/webrevs/2015/7901509/
> https://bugs.openjdk.java.net/browse/CODETOOLS-7901509
>
> After the last update of JIRA the Java Bug systems returns a title
> with no hash before t he bug ID:
>
> [JDK-8062493] JEP 243: Java-Level JVM Compiler Interface - Java
> Bug System
>
> The pattern which parses the bug ID and Bug summary in webrev has to
> be updated to accommodate for this change:
>
> sed 's/\[\(.*\)\] \(.*\) - Java Bug System<\/title>/\1 : \2/'
>
> vs the old:
>
> sed 's/\[#\(.*\)\] \(.*\) - Java Bug System<\/title>/\1 : \2/'
>
>
> Thank you and best regards,
> Volker
Looks good to me.
/Magnus
From volker.simonis at gmail.com Thu Sep 17 09:07:32 2015
From: volker.simonis at gmail.com (Volker Simonis)
Date: Thu, 17 Sep 2015 11:07:32 +0200
Subject: RFR(XXS): 7901509: Adjust bug title matching pattern after the
bugsystem changed the title format
In-Reply-To: <55FA7B68.2010807@oracle.com>
References:
<55FA7B68.2010807@oracle.com>
Message-ID:
Thanks Magnus!
I think I still need a sponsor from the code-tools project...
Regards,
Volker
On Thu, Sep 17, 2015 at 10:35 AM, Magnus Ihse Bursie
wrote:
> On 2015-09-16 19:43, Volker Simonis wrote:
>>
>> Hi,
>>
>> can somebody please review and sponsor this tiny fix:
>>
>> http://cr.openjdk.java.net/~simonis/webrevs/2015/7901509/
>> https://bugs.openjdk.java.net/browse/CODETOOLS-7901509
>>
>> After the last update of JIRA the Java Bug systems returns a title
>> with no hash before t he bug ID:
>>
>> [JDK-8062493] JEP 243: Java-Level JVM Compiler Interface - Java
>> Bug System
>>
>> The pattern which parses the bug ID and Bug summary in webrev has to
>> be updated to accommodate for this change:
>>
>> sed 's/\[\(.*\)\] \(.*\) - Java Bug System<\/title>/\1 : \2/'
>>
>> vs the old:
>>
>> sed 's/\[#\(.*\)\] \(.*\) - Java Bug System<\/title>/\1 : \2/'
>>
>>
>> Thank you and best regards,
>> Volker
>
>
> Looks good to me.
>
> /Magnus