Hotspot shell games

Volker Simonis volker.simonis at gmail.com
Sat May 30 00:20:59 PDT 2009


Thank you for the detailed explanation. It was indeed the situation
with the same changesets beeing applied in parallel to both
repositories that worried me. But aren't there already different
BugIds for the same change in the Bug database (those strange "shadow"
bugids starting with 2***) for exactly this purpose?

Volker

On Fri, May 29, 2009 at 8:01 PM, Kelly O'Hair <Kelly.Ohair at sun.com> wrote:
>
>
> 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
>



More information about the jdk6-dev mailing list