Getting jdk7 changes into jdk8

Dr Andrew John Hughes ahughes at redhat.com
Tue Jun 7 09:00:27 PDT 2011


On 09:54 Tue 07 Jun     , Andrew Haley wrote:
> On 07/06/11 00:38, Kelly O'Hair wrote:
> > 
> > Some questions have come up with regards to how the jdk7 changes will be pulled into jdk8.
> > 
> > Please be careful here, we do NOT want new changesets created in jdk8 for the exact same change
> > that was pushed into jdk7, we want the EXACT same jdk7 changeset in jdk8, not a re-creation.
> > The default behavior for 'hg import' is to re-create a new changeset (unless you use --exact).
> > This might sound like a silly difference, but it is actually very important.
> > 
> > If you re-create changesets for the same CR number, your integrator will be in a world of hurt when he/she
> > finds out that they cannot sync with the master jdk8 repos because of the same CR was used in 2 different
> > changesets.
> > 
> > The Release Engineering team will likely be doing syncs between jdk7 and jdk8 at jdk7 promotions or
> > maybe nightly, so unless you are in some kind or urgent hurry, please just let RE do this jdk7->jdk8 sync.
> 
> And, just to be clear, they will use "--exact" to solve this problem, right?
> Or is there something else they do instead?
> 

If you use hg import to bring an OpenJDK7 changeset into OpenJDK8 without the --exact option, it will apply
it against the tip of the repository and generate a unique identifier for it (making it a 'new changeset').
Then, when anyone attempts to pull from OpenJDK7 into OpenJDK8, Mercurial will not recognise that the backported
changeset in OpenJDK8 is the same as the one it's trying to pull from OpenJDK7 and try to merge it in, causing
conflicts.

With the --exact flag, the changes are applied against the parent of the original changeset and checked to see if
it generates the same ID as the original.  If not, the import is aborted.  This obviously means the parent changeset
must already exist in OpenJDK8.  It's this that has stopped us using this more often with IcedTea to backport to
release branches, as the branches don't have the parent changesets from HEAD and we don't want them to.  With OpenJDK7
and OpenJDK8, this shouldn't be an issue as we're forward-porting; OpenJDK8 should be all OpenJDK7's changesets plus
some more.

> Andrew.

-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and IcedTea
http://www.gnu.org/software/classpath
http://icedtea.classpath.org
PGP Key: F5862A37 (https://keys.indymedia.org/)
Fingerprint = EA30 D855 D50F 90CD F54D  0698 0713 C3ED F586 2A37


More information about the jdk8-dev mailing list