How to check out the openjdk source code from the mercurial repositories

[Erik Trimble]

On 3/10/2011 3:13 AM, Alan Bateman wrote:
> Fredrik Öhrström wrote:
>> I think it is important that a recent stock mercurial install
>> can check out the full openjdk with a single clone
>> command.
>>
>> I.e. you should not have to install special extensions just
>> to get the source code.
>>
>>
> I think this is a reasonable goal as it's probably confusing to folks
> today that they need to do seven "hg clone" commands to get everything
> (or else they need to go through hoops to get the forest extension
> working if they want the convenience of the fclone command). At the same
> time, and as Phil mentioned on another thread, I think most people are
> working in only one or a small subset of the repositories. If you've got
> the disk space then having all the repositories might not be a problem;
> the important thing (from a productivity perspective) is to continue to
> allow partial builds (meaning building a subset of the repositories and
> augmenting that with pre-built bits of the other repositories) and of
> course incremental builds within that when working in a specific area.
>
> -Alan


I see no compelling reason to architect things to a single-command full 
JDK source code pull using a stock Mercurial. That's a particular 
solution to one problem, and by no means the only solution.

If we would like to make pulling a full JDK source tree simpler, then by 
all means, let's include that as a possible goal.  But let's not put the 
cart before the horse, without fully understanding what we're looking 
for in the big picture.


Before we get into implementation details, we need to discuss what we're 
trying to accomplish.


As I see it, the source repository (in the generic sense, regardless of 
how it is actually technically implemented) has several demands made 
upon it:

(1) It should be designed to allow for maximum productivity of the 
developers (where ever they are); meaning, it should *not* define the 
way development works, but that developers should define how they work 
will work as a whole, and then the repo structure should reflect this.

     (1a) cloning/pulling the JDK should be as simple and as fast as 
possible. We need to define which has higher priority:  the ability, 
speed, and simplicity of pulling/cloning a component part of the JDK, or 
the ability/speed/simplicity of pulling/cloning the *entire* JDK

     (1b) supporting partial and incremental builds is highly desirable


(2) It should provide for reasonable flexibility in forking and movement 
of large chunks of code between portions of the JDK

         (2a) In particular, it should allow for the possibility of 
replacing chunks of the JDK wholesale with outside sources.  The titular 
example is the VM, which should be able to be replaced without screwing 
up the rest of the JDK repository(s). However, the VM is not the only 
place this is beneficial - we need to make sure that any defined 
component can have a forklift replacement, without damaging the rest of 
the JDK repository.

(3) Maintainers, Performance Analysis, and QA/QE folks need the ability 
to quickly and easily identify discrete points in the source code 
evolution - that is, the JDK must have some way to provide snapshot 
capability (where, by "snapshot", I mean that it is possible to maintain 
a system where a perpetual reference to a particular state of the JDK 
repository can be made).


What other *DESIGN* goals do people see should have for the JDK repository?

-- 
Erik Trimble
Java System Support
Mailstop:  usca22-123
Phone:  x17195
Santa Clara, CA