Bulk Push request for Hotspot 22 Build 01...

[Erik Trimble]

This is a request to integrate the new Hotspot 22 Build 01 codebase into
the JDK 7u train.

Unfortunately, after thorough investigation, we *cannot* do a merge of
the Hotspot 22 repository with the existing Hotspot 21-b17 -based
repository currently residing in jdk7u/jdk7u-dev/hotspot .

Earlier today, I had hoped to be able to this merge, which, while it
originally looked a bit messy, would retain all history and all tags.

However, we have run into serious Mercurial issues with the merge.

Here is the problem:

jdk7u/jdk7u/hotspot is based on HS21-b17.  HS22-b01 forked off HS21 at
b13.  Thereafter, codefixes were pushed into both repositories
separately, so there are different changesets with the same code changes
and CRs in the two repositories. In addition, HS22 has unique work
interspersed with the cross-ported work from HS21.  So, both repos are
divergent.

While the relaxed jcheck rules allow for duplicate CRs in 7u, the
Mercurial merge is much trickier than it originally looked.

John Coomes has done several passes at the merge, and we're having
extreme difficulty in getting the merged repository (that is, the result
of pulling HS22 into HS21-b17) to be identical (code-wise) to HS22.

That is, the merged results *must* result in the codebase being
identical to HS22, and that is not currently happening. We've tried a
couple of options, including telling Mercurial to use the incoming file
in all cases of a conflict, but we're still ending up with a diff of the
merge vs raw HS22 repositories showing output (i.e. differences
existing).

We can't resolve these merge problems. So, we're left with the only
option to wholesale replace - that is, blow away the existing
jdk7u/jdk7u/hotspot repository (and, all dependent repositories), and
copy in the HS22 repository.

We're going to lose a bit of history; I'm sorry, but this is
unavoidable. Code consistency is paramount.  As a side note, John has
also found a couple of changes that are in HS21-b17 that AREN'T in HS22
(mostly copyright, but there's at least one other outstanding fix not in
HS22). We will have to audit this, and add them to a future HS22 build.
I'm not using a merge of code that results in something which hasn't
been tested together.

On a similar note, there can be no webrev for this push. Webrev will
attempt to do a merge itself when computing changes, and since the merge
won't work correctly, the webrev output is garbage (i.e. it will produce
output, but incorrect output). 

So, no webrev, either.


I deeply apologize for this situation, but I see no other recourse. 


So, we're proposing to do this:

1) delete the jdk7u/jdk7u-dev/hotspot and all dependent repositories

2) copy in the hsx/hsx22/hotspot repository to all the above places;
said copy will happen INSIDE the Hg repositories, and is a filesystem,
rather than Mercurial, operation

3) add to the push blacklist one changeset from the HS21-b17 build, to
insure that any pushes from that older repository are rejected

4) publish a list of all repositories which have been affected

5) along with that list, make it explicit that everyone needs to delete
their local copies and re-clone any affected repository 




-- 
Erik Trimble
Java Platform Group - Infrastructure
Mailstop:  usca22-317
Phone:  x67195
Santa Clara, CA
Timezone: US/Pacific (UTC-0800)