Setting up the Mercurial Repositories for Sumatra
Deneau, Tom
tom.deneau at amd.com
Mon Dec 10 11:36:57 PST 2012
John --
The A,B,C repository proposal looks fine.
For the branching, I am not familiar with the MQ flat patch file procedure (yet another Mercurial branching option!) but if it works with the mlvm project, it will probably work for us. Is there documentation that explains how it is used on mlvm?
-- Tom
From: John Rose [mailto:john.r.rose at oracle.com]
Sent: Friday, December 07, 2012 6:54 PM
To: Deneau, Tom
Cc: sumatra-dev at openjdk.java.net
Subject: Re: Setting up the Mercurial Repositories for Sumatra
On Dec 6, 2012, at 8:36 AM, Deneau, Tom wrote:
How do we get the initial Mercurial repositories created for the Sumatra project?
We believe a clone of the http://hg.openjdk.java.net/lambda/lambda forest will be a good starting point.
Again, what Brian said. (Thanks, Brian.)
John Coomes and I have been talking about this for a while, and we have a proposal we'd like to float. It is based on the following observations:
A. We need a stable prototype which can be built using standard procedures.
B. We need a "sandbox" or "workbench" for maybe-throwaway experiments in modifying the JVM and JDK (not to interfere with A).
C. We need a part of the "workbench" to share flat files, small proofs of concept, and other ad hoc resources (not to interfere with A or B).
D. We do not need direct mergability into jdk8 (same as lambda repos, which do not merge up directly, and does not need to pass jcheck).
E. The workbench version of things needs to be malleable by simultaneous independent workers.
F. However, workbench experiments should be shareable, when the workers want to collaborate.
G. Successful, maturing experiments should be shareable with a wider audience, by moving changesets to the stable prototoype (A).
H. Eventually (as with Project Lambda) the prototype can be moved (after further development) into the main jdk source base (JDK 9 or whichever).
I. Unlike big projects like HotSpot, Sumatra will not grow very large, and so does not need a high level of codification and formality.
J. We will (per OpenJDK) distinguish the roles of author, committer, and reviewer.
In concrete terms, we think this comes to something like the following repositories:
A. http://hg.openjdk.java.net/sumatra/sumatra/{hotspot,jdk,langtools,...}<http://hg.openjdk.java.net/sumatra/sumatra/%7bhotspot,jdk,langtools,...%7d> (cloned from jdk8, buildable & testable, occasionally refreshed and rebased)
B. http://hg.openjdk.java.net/sumatra/sumatra-dev/{hotspot,jdk,langtools}<http://hg.openjdk.java.net/sumatra/sumatra-dev/%7bhotspot,jdk,langtools%7d> (bundle of independent branches, occasionally rebased on A)
C. http://hg.openjdk.java.net/sumatra/sumatra-dev/scratch (initially empty workbench shelf, for sharing artifacts other than JDK source changes)
John Coomes is looking into configuring these repos with suitable "jcheck" options to relax some of the OpenJDK rules on changeset structure, and to allow B. to have multiple simultaneous branches.
In addition I have a question about branching. Assuming the Sumatra project is going to have a main trunk and also some experimental branches that may or may not get merged into the main trunk, is there a page that explains which of the many branching models supported by Mercurial would be used?
>From looking at other projects it looks like separate repositories are made for each branch? If we went that way, what is the process when someone wants to create a new branch?
Mechanically, any committer can create a new branch, and the contents of the branch are up to the committer. I would ask that branch names would be briefly reviewed, by Reviewers, before creation, at least at first, so that we build a habit of naming experiments with some consistency. (I'm not thinking of anything heavyweight; see the mlvm repository for some examples.)
Before we jump in, though, I have one big worry, and it's the same as yours, Tom: Which practice of branching will work for us? I have enjoyed using the simplest possible version: Flat patch files, handled with MQ (hg qpush etc.) and manually rebased. This gives maximum flexibility, but may be too unfriendly for us. If there is a HG branch model that works better than (versioned) flat patch files, let's use it.
If we actually go with flat patch files, then the mlvm provides a starting point for a model.
http://hg.openjdk.java.net/mlvm/mlvm/hotspot
One more caveat: Whatever branch model we use, it needs to interoperate with the OpenJDK servers, which are an old rev. of HG.
Best wishes,
- John
More information about the sumatra-dev
mailing list