From martinrb at google.com  Wed May  2 20:36:42 2018
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 2 May 2018 13:36:42 -0700
Subject: RFR Mercurial trees extension: Fixes for hg 4.2-4.5
In-Reply-To: <20180306131316.288726455@eggemoggin.niobe.net>
References: <20180306131316.288726455@eggemoggin.niobe.net>
Message-ID: <CA+kOe0-ems4AUWzmfHEY-X=NmHddYbCF6jSuESP1X06U7+rASA@mail.gmail.com>

Hi Mark,

These changes to trees have not made it into
http://hg.openjdk.java.net/code-tools/trees/
This is becoming a problem because mercurial 4.5.3 is the default on Ubuntu
18.04 LTS (and debian testing).

Upstream mercurial API churn continues, and there is an additional recent
upstream commit that will have to be dealt with (Google might contribute a
fix)
https://www.mercurial-scm.org/repo/hg/rev/54435fd09f1d

trees is less useful than it used to be, given that jdk10+ will not need
it.  But we'll have to deal with jdk8u for another few years.

Thanks.

On Tue, Mar 6, 2018 at 1:13 PM, <mark.reinhold at oracle.com> wrote:

> http://cr.openjdk.java.net/~mr/rev/trees/
>
> Tested against hg 1.1-4.5, including remote tests.
>
> Question: In some of the code-tools repos, some changeset comments
> include bug numbers from the CODETOOLS JBS project.  A couple of the
> recent changesets in the trees repo have bug numbers, but the most
> recent one does not.
>
> Do we want to use CODETOOLS bug numbers in the trees repo uniformly,
> going forward?  What about other hg-tools repos?
>
> Personally, it seems like overkill to me since these tools are small,
> and usually change only rarely, but I'd like to hear other opinions.
>
> - Mark
>

From martinvonz at google.com  Wed May  2 20:41:52 2018
From: martinvonz at google.com (Martin von Zweigbergk)
Date: Wed, 02 May 2018 20:41:52 +0000
Subject: RFR Mercurial trees extension: Fixes for hg 4.2-4.5
In-Reply-To: <CA+kOe0-ems4AUWzmfHEY-X=NmHddYbCF6jSuESP1X06U7+rASA@mail.gmail.com>
References: <20180306131316.288726455@eggemoggin.niobe.net>
 <CA+kOe0-ems4AUWzmfHEY-X=NmHddYbCF6jSuESP1X06U7+rASA@mail.gmail.com>
Message-ID: <CAESOdVBTx3GDXO56TiaBGRPMa9irNxU7kakSJw9Y6LqqVobXog@mail.gmail.com>

On Wed, May 2, 2018 at 1:36 PM Martin Buchholz <martinrb at google.com> wrote:

> Hi Mark,
>
> These changes to trees have not made it into
> http://hg.openjdk.java.net/code-tools/trees/
> This is becoming a problem because mercurial 4.5.3 is the default on
> Ubuntu 18.04 LTS (and debian testing).
>
> Upstream mercurial API churn continues, and there is an additional recent
> upstream commit that will have to be dealt with (Google might contribute a
> fix)
> https://www.mercurial-scm.org/repo/hg/rev/54435fd09f1d
>

And also these:

https://www.mercurial-scm.org/repo/hg/rev/e2a0aaec7d86
https://www.mercurial-scm.org/repo/hg/rev/a9ea2b1e5c4b


>
> trees is less useful than it used to be, given that jdk10+ will not need
> it.  But we'll have to deal with jdk8u for another few years.
>
> Thanks.
>
> On Tue, Mar 6, 2018 at 1:13 PM, <mark.reinhold at oracle.com> wrote:
>
>> http://cr.openjdk.java.net/~mr/rev/trees/
>>
>> Tested against hg 1.1-4.5, including remote tests.
>>
>> Question: In some of the code-tools repos, some changeset comments
>> include bug numbers from the CODETOOLS JBS project.  A couple of the
>> recent changesets in the trees repo have bug numbers, but the most
>> recent one does not.
>>
>> Do we want to use CODETOOLS bug numbers in the trees repo uniformly,
>> going forward?  What about other hg-tools repos?
>>
>> Personally, it seems like overkill to me since these tools are small,
>> and usually change only rarely, but I'd like to hear other opinions.
>>
>> - Mark
>>
>
>

From martinrb at google.com  Wed May 30 02:49:48 2018
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 29 May 2018 19:49:48 -0700
Subject: RFR Mercurial trees extension: Fixes for hg 4.2-4.5
In-Reply-To: <CAESOdVBTx3GDXO56TiaBGRPMa9irNxU7kakSJw9Y6LqqVobXog@mail.gmail.com>
References: <20180306131316.288726455@eggemoggin.niobe.net>
 <CA+kOe0-ems4AUWzmfHEY-X=NmHddYbCF6jSuESP1X06U7+rASA@mail.gmail.com>
 <CAESOdVBTx3GDXO56TiaBGRPMa9irNxU7kakSJw9Y6LqqVobXog@mail.gmail.com>
Message-ID: <CA+kOe0_mAP-+mX17sKypuLX8XnJ9O3D9yYfDR+GtDiGAPnrBSA@mail.gmail.com>

If and when maintainers decide to fix the trees extension to work with
recent versions of merrcurial,
my colleague Martin von Zweigbergk's fixes are available here:
https://bitbucket.org/martinvonz/openjdk-trees
I had been working around by building my own backlevel mercurial (It's
surprisingly easy to build).

On Wed, May 2, 2018 at 1:41 PM, Martin von Zweigbergk <martinvonz at google.com
> wrote:

>
>
> On Wed, May 2, 2018 at 1:36 PM Martin Buchholz <martinrb at google.com>
> wrote:
>
>> Hi Mark,
>>
>> These changes to trees have not made it into
>> http://hg.openjdk.java.net/code-tools/trees/
>> This is becoming a problem because mercurial 4.5.3 is the default on
>> Ubuntu 18.04 LTS (and debian testing).
>>
>> Upstream mercurial API churn continues, and there is an additional recent
>> upstream commit that will have to be dealt with (Google might contribute a
>> fix)
>> https://www.mercurial-scm.org/repo/hg/rev/54435fd09f1d
>>
>
> And also these:
>
> https://www.mercurial-scm.org/repo/hg/rev/e2a0aaec7d86
> https://www.mercurial-scm.org/repo/hg/rev/a9ea2b1e5c4b
>
>
>>
>> trees is less useful than it used to be, given that jdk10+ will not need
>> it.  But we'll have to deal with jdk8u for another few years.
>>
>> Thanks.
>>
>> On Tue, Mar 6, 2018 at 1:13 PM, <mark.reinhold at oracle.com> wrote:
>>
>>> http://cr.openjdk.java.net/~mr/rev/trees/
>>>
>>> Tested against hg 1.1-4.5, including remote tests.
>>>
>>> Question: In some of the code-tools repos, some changeset comments
>>> include bug numbers from the CODETOOLS JBS project.  A couple of the
>>> recent changesets in the trees repo have bug numbers, but the most
>>> recent one does not.
>>>
>>> Do we want to use CODETOOLS bug numbers in the trees repo uniformly,
>>> going forward?  What about other hg-tools repos?
>>>
>>> Personally, it seems like overkill to me since these tools are small,
>>> and usually change only rarely, but I'd like to hear other opinions.
>>>
>>> - Mark
>>>
>>
>>