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/<title>\[#\(.*\)\] \(.*\) - 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: <CA+3eh13et5Kw-Q8zAGtF65BjatVd7DFaGBXeViYfgoz=xge+Bw@mail.gmail.com> References: <CA+3eh13et5Kw-Q8zAGtF65BjatVd7DFaGBXeViYfgoz=xge+Bw@mail.gmail.com> 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: > > <title>[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/<title>\[#\(.*\)\] \(.*\) - 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: <CA+3eh13et5Kw-Q8zAGtF65BjatVd7DFaGBXeViYfgoz=xge+Bw@mail.gmail.com> <55FA7B68.2010807@oracle.com> Message-ID: <CA+3eh11YWysRy==WehqExQ3AQ_7G4GgxDb_v+Gqy-22xCMRigA@mail.gmail.com> 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 <magnus.ihse.bursie at oracle.com> 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: >> >> <title>[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/<title>\[#\(.*\)\] \(.*\) - Java Bug System<\/title>/\1 : \2/' >> >> >> Thank you and best regards, >> Volker > > > Looks good to me. > > /Magnus