OpenJDK6 Repositories

[Kelly O'Hair]

Andrew John Hughes wrote:
> 2008/12/8 Kelly O'Hair <Kelly.Ohair at sun.com>:
>>  * They should match the contents of the OpenJDK6 source bundles, except:
>>    - No control directory, these files are in the top repository now
>>    - Previously you had to 'cd control/make && gnumake', now just 'cd . &&
>> gnumake'
>>    - README-builds.html is in the top repository, it's movement has created
>>      a little confusion in the changesets, ultimately we will have one copy.
> 
> This causes issues with supporting the new hg tree in IcedTea as the
> patches are against paths with the control subdirectory present.  Is
> the intention for 6 to now follow 7 and not have a control directory,
> and will this extend to future bundles?

Yes and yes. For the most part the changes are simple, the control/make/Makefile
becomes ./Makefile and the control/make/make directory becomes the ./make
directory. Less than 20 files are involved as I recall.

The source bundle contents will look exactly like the forest, minus all the
.hg/ directories.

> 
>>  * Contributed changes should be documented in the changeset comments,
>>    if the contribution information is missing please let me know
>>  * These repositories were created from the TeamWare workspaces and a set
>>    of patches and documentation on those patches, we may have to re-create
>> them.
>>    If we re-create repositories again, the old ones will not be related
>>    to the new ones.  So any changesets you create with your clones
>>    should be viewed as temporary until the final repositories are put in
>> place.
>>  * The hotspot repository may be completely replaced when we upgrade to
>> HS14,
>>    so when that happens you may need to re-clone the hotspot repository.
>>
> 
> Why not just pull from the latest HotSpot tree to JDK6?  Or will JDK6
> dispense with a HotSpot directory altogether?

There are some technical issues, and that may be the way it happens,
it just remains to be seen.
The hotspot express release requires that the VM be 100% operational for
multiple jdk releases, this will place different requirements on the
hotspot sources than other parts of openjdk6.
We want the most stable hotspot we can get in the openjdk6, I assume.

Mercurial changesets cannot be pulled and pushed around without also
getting all the parent changesets connected to them.
Changesets can be bundled and re-applied to another repository, but
they actually become new changesets (different revs) that are unrelated
to the original changeset. Picking and choosing changesets will probably
mean unrelated repositories.
Some decisions need to be made about how the hotspot and openjdk6
team wants to manage this over the long haul.

> 
>> Please let me know if you see anything wrong with these repositories.
>>
> 
> Apart from being quite slow, they seem to work ok so far.  It took two
> goes to get a checkout, the build stalled and eventually timed out on
> jdk.

I assume your 'checkout' means 'fclone'?

Cloning a forest is usually a one time operation, you keep a forest
around, and just do an occasional 'hg fpull -u' to update it, or that's
what I do. The 'pull' operations are usually fast.

We will continue to provide source bundles too, and it may make more sense
in some situations to just use the source bundles.

-kto

> 
>> The target date for official repositories is next week, once it is official
>> we can add more changesets to correct problems, but we can't go back and
>> change the changesets already created.
>>
>> -kto
>>
>