[RFR] jdk9.0.4+12 + functionality

[Andrey Petushkov]

> On 10 Apr 2018, at 14:38, Edward Nevill <edward.nevill at gmail.com> wrote:
> 
> On Tue, 2018-04-10 at 09:04 +0000, Andrey Petushkov wrote:
>> The purpose of http://cr.openjdk.java.net/~apetushkov/aarch32jdk9.0.4%2b12/ is yes, only to bump to 9.0.4+12 baseline, nothing more. And yes, I've presumed if I manage to get a better patch I'll present it in some form like that, not the 2G webrev
>> Anyway, let me sort the update thing out, I still don't get it whether it's my fault or somebody has done something nasty in upstream..
>> 
>> 
> 
> I think it is mercurial/webrev. It is not very intelligent when it come to merges.
> 
> I just tried merging only the root as follows.
> 
> hg pull -u http://hg.openjdk.java.net/jdk-updates/jdk9u
> hg merge
> hg commit
> 
> [note: I did get some conflicts which I had to resolve]
> 
> If I then do
> 
> hg outgoing
> 
> I then get 100s of outgoing changesets
> 
> Eg.
> 
> ed at basil:~/openjdk/aarch32/jdk9$ hg outgoing | egrep ^changeset | wc
>    881    1762   27311
> 
> 
> These all conflict because they contain within them all the merges which duplicate all the changes. Therefore when I try to import I get conflicts because it is trying to apply the same change multiple times.
Yes, exactly. That’s why I’ve done a little bit in other way:
hg pull -u …/jdk9u
hg up tip
hg merge
hg commit

This way the diff for my changeset is all the changes done for aarch32-jdk9 and those are much smaller than upstream (especially for the root repo)
> 
> What is needed is just the last changeset (IE the one I committed above)
> 
> hg log
> changeset:   2693:aad3bd4239d3
> tag:         tip
> parent:      1812:563bcbb5ea81
> parent:      2692:1b1226687b89
> user:        enevill
> date:        Tue Apr 10 12:19:54 2018 +0100
> 
> I can then do
> 
> hg export 2693 > ../2693
> 
> In a freshly cloned jdk9 I can then do
> 
> hg import ../2693
> 
> and it imports cleanly.
Yes, of course I can do it. And it is fine for you to verify the update but I suppose we still need the "full version” patch which has all upstream history in it, not only the diff
> 
> These are 100s of times smaller than the GB generated by webrev.
> 
> You can then post the single changeset for review (1 for each subtree) and I will be able to import it.
Working on it, will send ASAP

Thank you,
Andrey
> 
> All the best,
> Ed.
>