Mercurial repo for openjdk6 drops

[Mark Wielaard]

Hi Kelly,

On Wed, 2008-09-17 at 10:26 -0700, Kelly O'Hair wrote:
> Speaking from experience, any attempts at cleanly creating changesets
> from TeamWare data alone is a waste of time. Just doesn't work well.
> Granted we have pretty complete OpenJDK6 changeset data (data beyond
> the TeamWare data) and could potentially do this, it's quite a bit of
> grunt work to accomplish. Before we go off on this kind of adventure
> we need to make sure the time spent is worth it.

It depends on what your goal is. To be useful having any changeset data
that is more fine grained grained than the big source code drop changes
we have now is already enough. While it would be great to have an all
singing and dancing mercurial repo that exactly matches the teamware
changesets going back to the birth of openjdk6 and that then is
essentially a tree that can be easily merged with openjdk7 would be
super great. But to be useful just having the changes as they are going
in (even if it is just patches posted to the list at the time they are
applied to the internal teamware tree) would be of great value imho.

> A different approach would be to create changesets per build/promotion,
> but those kind of large changesets can have limited usefulness.

That is what we have in http://icedtea.classpath.org/hg/openjdk6 now. It
is indeed of limited usefulness. But already very useful to actually see
what really went into the tree. Being able to just hg diff between
source code drops really helps getting a better feeling for the changes
in the code in my experience.

So in order of preference I would like to see:

- Patches posted to the mailinglist going forward whenever they are
applied to the internal teamware tree until we have a real public
mercurial repository.

- Getting individual changesets as they were applied from openjdk6 build
b05 so we can build up at least some real history of the tree.

- Getting the baseline openjdk7 tree from which the original openjdk6
was derived, so it will be easier to track essential changes from the
openjdk7 tree since then.

- Getting the changesets from that version of the openjdk7 tree to the
first openjdk7 tree that is in mercurial (we already have early source
drop changes from the early svn days converted to mercurial in
http://icedtea.classpath.org/openjdk)

- Nirvana - aka, combine all the above to construct a mercurial tree
with all the above changesets that covers both openjdk6 and openjdk7 for
really easy merging between the tree.

> Also, don't forget that the OpenJDK7 sources are a Mercurial forest,
> not just one repository. I assume that we want to mimic the same
> forest layout, keeping the langtools, corba, jaxp, jaxws, and hotspot
> sources in their own repositories, separate from the core 'jdk' repository.
> That allows us to do some plug and play with these repositories
> between OpenJDK6 and OpenJDK7.

How likely is it that we will actually plug and play these
sub-repositories between openjdk6 and openjdk7?

If we can easily do that, and it is likely that we will not just share
individual patches between trees but whole repository merges then that
would be interesting. But if openjdk6 will essentially be a separate,
mainly maintenance, tree then I think just having one tree instead of a
forest of repositories makes sense. Since forests do complicate things a
bit. So it must be clear that there is a real gain from having them.

Cheers,

Mark