David Herron wrote:
Hi Kelly, thank you, and I also found the same thing described on the internal page you set up.
I'm thinking right now my original question probably doesn't have a strong use-case-justification. Is there any reason to check out just one of the repositories? (just one tree rather than the whole forest)
Yes, in some cases, there may be a valid reason to just get one repository or a partial forest. A developer may wish to focus on certain repositories and ignore the rest until it's time to push the changes. It depends on what the team considered acceptable practice. For example, the hotspot team does almost all there work without ever building a jdk themselves. They have the ability to isolate their work and test it using a promoted jdk image. All repositories (except for the enclosing repository) is independently buildable and can be worked on by developers independently.
However there is the issue of the individual team repositories. Is there a way to discover the full set of repositories we're hosting on openjdk.java.net?? And also the parent/child relationships between those repositories?
There are multiple dimensions here. The basic OpenJDK forest contains 7 unique repositories, an enclosing repository plus corba, hotspot, jaxp, jaxws, jdk, and langtools. Every repository is represented as a pair, the pull (http) repository and the push (ssh) "-gate" repository. So each forest is actually implemented with 14 (7*2) repositories. The master area is jdk7/jdk7 and it's child team areas are: jdk7/2d jdk7/awt jdk7/build jdk7/corba jdk7/hotspot (has children: jdk7/hotspot-comp, jdk7/hotspot-gc, jdk7/hotspot-rt, jdk7/hotspot-svc) jdk7/i18n jdk7/jaxp jdk7/jaxws jdk7/jsn (may be a child of jdk7/tl?) jdk7/l10n jdk7/modules (may be a child of jdk7/tl? Or special project?) jdk7/nio2 (may be a child of jdk7/tl? Or special project?) jdk7/swing jdk7/tl The jdk7/modules and jdk7/nio2 may be considered "projects" and may or may not push directly to the master area. I'm not sure about those, the team gets to decide. A project may create many changesets that could at project completion get folded together into fewer official changesets that get pushed into the master area eventually. It depends on the team and the project. We are trying to be flexible but at the same time make sure the changesets that get integrated follow the rules we have setup. -kto
(This might be OT for discussion in the guide)
- David
Kelly O'Hair wrote:
These are forests, use fclone rather than clone, and the first time you need to make sure the destination does not exist, e.g.
rm -f -r my2d hg fclone http://hg.openjdk.java.net/jdk7/2d my2d
-kto
David Herron wrote:
The discussion about per-component repositories [1] doesn't seem to match reality.
If one wanted to check out just one component-area workspace it's not clear how to proceed from the guidebook description. It says the URL pattern is: <release>/<project>{-gate}?/<component>
<release> obviously is 'jdk7' ... but then precisely what value is used for '<project>' and '<component>'
The page lists project names such as '2d' so perhaps one of these would work
hg clone http://hg.openjdk.java.net/jdk7/2d hg clone http://hg.openjdk.java.net/jdk7/jdk7/2d
But those result in a directory containing just the license & README & make files, and no source.
On the other hand this following results in just the CORBA repository being checked out
hg clone http://hg.openjdk.java.net/jdk7/jdk7/corba
- David Herron
[1] http://openjdk.java.net/guide/repositories.html#term _______________________________________________ guide-discuss mailing list guide-discuss@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/guide-discuss
guide-discuss mailing list guide-discuss@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/guide-discuss