Bulk Push request for Hotspot 22 Build 01...

[Dalibor Topic]

Hi Erik, hi John,

Thanks for the detailed account of the issues with the merge, and
for investigating that path. I approve the proposal to replace & document 
and integrate without a webrev as outlined in steps 1-5 of your e-mail. 

Edvard, the Technical Lead for JDK 7 Updates has voted in preference of 
replace & document as well here: 
http://mail.openjdk.java.net/pipermail/jdk7u-dev/2011-August/000166.html
so you have green light for this hopefully not too exciting bit of 
repository brain surgery.

cheers,
dalibor topic

On 8/13/11 1:51 AM, Erik Trimble wrote:
> 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 
> 
> 
> 
> 



-- 
Oracle <http://www.oracle.com>
Dalibor Topic | Java F/OSS Ambassador
Phone: +494023646738 <tel:+494023646738> | Mobile: +491772664192 <tel:+491772664192>
Oracle Java Platform Group

ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg

ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Geschäftsführer: Jürgen Kunz, Marcel van de Molen, Alexander van der Ven

Green Oracle <http://www.oracle.com/commitment> Oracle is committed to developing practices and products that help protect the environment