United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
JDK-6631003 : Add hg tip changeset to build image

Details
Type:
Enhancement
Submit Date:
2007-11-16
Status:
Closed
Updated Date:
2014-03-03
Project Name:
JDK
Resolved Date:
2011-05-10
Component:
infrastructure
OS:
generic,windows_xp
Sub-Component:
build
CPU:
generic
Priority:
P3
Resolution:
Fixed
Affected Versions:
7
Fixed Versions:

Related Reports
Backport:
Duplicate:
Duplicate:
Relates:
Relates:

Sub Tasks

Description
With Mercurial, a single repository changeset number identifies the state of the complete source repository. If this changeset (or set of changesets) could be somehow recorded with the built bits, then given any build you could quickly and easily reconstruct the exact same files that were used at build time.

How this is handled with hotspot and the rest of the jdk still needs investigation.

And RE builds from source bundles would need to be addressed, perhaps by recording the changesets inside the source bundle somehow.
Also use the tags in the repository to determine what build number this build is based on, if no build number is supplied, e.g. use: hg tags
tip                               26:a900069e9700
jdk7-b31                          22:3300a35a0bd5
jdk7-b30                          19:2dab2f712e18
jdk7-b29                          16:31e08f70e88d
jdk7-b28                          13:56652b46f328
jdk7-b27                          12:11b4dc9f2be3
jdk7-b26                           9:9410f77cc30c
jdk7-b25                           8:cbc8ad9dd0e0
jdk7-b24                           0:cfeea66a3fa8

To get the build number for the jdk version string of a build.
The goal is to provide the Mercurial tips for every source repository used to build JDK7 in the built image so that it would be possible to re-construct the sources from that built image.

                                    

Comments
EVALUATION

Just ideas so far... one issue is identifying a repository of the forest relative to the root of the forest.

Each repository would get a managed file ".identification" which would contain:

For example, the topmost one would have:
   root=.
   directory=.
   description=Root of the JDK Source Tree

The corba one would have:
   root=..
   directory=corba
   description=Corba Sources

The root gives a relative path to the root of the forest, the directory from the root, and a description of what this part of the forest is. This data also provides a way to verify the forest layout.

A second file called ".changesetid" would not be a managed file and would be created before the source bundles are created, and non-existent if they can't be created because you don't have repositories (building from raw source trees) or don't have access to 'hg'. These files would just contain a changeset=id, created with:
   hg tip --template '{node}\n'

So somehere the action:
   TREES:=$(shell hg ftrees)
   if [ "$(TREES)" != "" ] ; then
     for i in $(TREES) ; do
        (cd $i && hg tip --template 'changset={node}\n' > .changesetid )
     done
   fi
needs to happen. Before source bundles are created, and before these files are needed.

The Makefiles then would be sensitive to the existence of the .changesetid files and allow for them to not exist where they are used, they might not be there in all cases. But when they are there, do something like:
jdk_source_information.txt:
   $(RM) $@
   echo "# JDK Source Information" > $@
   if [ "$(TREES)" != "" ] ; then
     for i in $(TREES) ; do
       if [ -f ${i}/.identification ] ; then
         cat ${i}/.identification >> $@
         if [ -f ${i}/.changesetid ] ; then
           cat ${i}/.changesetid >> $@
         fi
       fi
     done
   fi

Resulting in a file:

# JDK Source Information
root=.
directory=.
description=Root of the JDK Source Tree
changset=BIGHEXNUMBER
root=..
directory=corba
description=Corba Sources
changset=BIGHEXNUMBER
...

Left in the jdk install tree that could be used to re-create the source tree for that build of the jdk.

Just a first guess as to how this could work...


-kto
                                     
2008-04-03
EVALUATION

That's about what I was expecting, although I was originally envisioning of the directory entry just having:

    directory=.
    ...deleted...
    directory=deploy
    ...deleted...
    directory=jdk
    ...deleted...
    directory=jdk/make/closed
    ...deleted...

This would match the relative respository locations so that you simply append the directory values to get the relative paths.

I expect to add this file into my JCE build jars, so I'll need it by the time javax is built, or it will need to be built by my code.
                                     
2008-04-03
EVALUATION

I thought that's what I had. The root is to know how to get to the top of the forest, so given any repository in the forest you could test to see if the repository was placed in the forest properly with:

   if [ "`cd ${root}/${directory} && pwd`" != "`pwd`" ] ; then
     echo "Repository not positioned in the forest per the .identification information"
   fi

Maybe another example helps, The jdk/src/closed one would have:
   root=../../..
   directory=jdk/src/closed
   description=Closed JDK Sources

This .identification file would be a permanent file in the repository, at the root of the repository. It's saying that to get to the root of the forest, you 'cd ${root}'. And if this repository is not located at ${root}/${directory} something is wrong, or the repository is not currently part of a forest.
                                     
2008-04-03
EVALUATION

http://hg.openjdk.java.net/jdk7/build/rev/3bd41d40ab97
http://hg.openjdk.java.net/jdk7/build/jdk/rev/dc63c52bc61f

And all repos got .hgtip added to their .hgignore files.
                                     
2011-04-26
EVALUATION

http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/4ca65400aa33
                                     
2011-04-30
EVALUATION

http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/4ca65400aa33
                                     
2011-05-05



Hardware and Software, Engineered to Work Together