Bulk Push request for Hotspot 22 Build 01... (original) (raw)

Dalibor Topic dalibor.topic at oracle.com
Fri Aug 12 17:15:30 PDT 2011

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

More information about the jdk7u-dev mailing list