Hotspot shell games

[Kelly O'Hair]

Volker Simonis wrote:
>>   * Tag the rev in the jdk7/hotspot repo with a name jdk6-b17, the
>>     rev that matches what is in the hsx14 repo
> 
> Is this really possible? I thought the HS which is now in 6u14 (and in
> HSX14) was branched from the jdk7/hotspot sometimes around hotspot
> build 9/10 of the jdk7/hotspot. Afterwards, the hotspot version was
> incremented to 15 in jdk7/hotspot while there have been about six more
> builds of HS 14 in the HSX14 repository. From my understanding, the
> change history in jdk7/hotspot and HSX14 is different after HSX has
> been branched off from jdk7/hotspot and I can't imagine how one can
> now find a changeset in jdk7/hotspot which matches the hotspot version
> in HSX14. After all, the whole purpose of branching HSX14 is to
> stabilize it while the development can proceed in jdk7/hotspot. Or am
> I missing something here?

Mercurial tags can be created after the fact. A tag is just a reference
or name to a changeset ID, they can also be updated or changed later.
They are very simple things.

I'll ignore "HSX14", and call it "jdk6/hotspot", but if you like, you can
replace the names as you read this. ;^)

If jdk6/hotspot work is done in a jdk6/hotspot repository, and new changesets are
added or new tags created, you should be able to pull those changesets
into jdk7/hotspot, merge and commit them there too.
The end result is that all the jdk6/hotspot changesets are in jdk7/hotspot,
then you could 'hg clone -r jdk6-bNN' from either repository and get the
exact same thing.

The trick is to create jdk6/hotspot changesets in an jdk6/hotspot repository
so that the graph of changesets for jdk6/hotspot are all connected together.
The sync to jdk7/hotspot effectively adds any jdk6/hotspot changesets and merges
with the current jdk7/hotspot tip, creating a new jdk7/hotspot tip.

The jdk6/hotspot repository acts as a branch, yet no hg branches are used.
Someone would occasionally need to make sure the jdk6/hotspot changes that
are not in jdk7/hotspot get pulled over (a sync).

The tricky part is transplanting or cherry picking 1 changeset from
jdk7/hotspot back to jdk6/hotspot without accepting the whole graph
of changesets above it. Unless we relax the jcheck rules around this,
two changesets with the same bugid cannot exist in one repository, so
a new bugid is needed to do any transplants (where a new changeset is
created for the same patch or code change).

-kto

> 
> Regards,
> Volker