Friday Sep 05, 2008

Using the Mercurial Forest extension for OpenSolaris onnv-gate

Some background

This is really only relevant to those people doing development on the OpenSolaris onnv-gate that are inside Sun, but it since there is nothing private about it I'm posting it publicly so google can find it.

With the transition from Teamware to Mercurial the onnv-gate source code is now held in two separate repositories. The main repository holding the overwhelming majority of the source code, which is opensourced under various licenses but mostly CDDL, is called "onnv-gate" the source code is in the mercurial repository in a subdirectory called usr/src. The much smaller closed source is in a separate repository that is nested inside the "onnv-gate" as the usr/closed subdirectory.

The usr/src part can be built either by using the downloadable (and redistributable) binaries which make up a proto area for the closed source bits, or the usr/closed part can be built from source along with usr/src. If building both from source then the usr/src and usr/closed mercurial repositories must be in sync otherwise there will be a high risk of either build failures or buggy binaries.

The Mercurial forest extension provides a way to make sure that nested repositorys such as onnv and onnv-closed are always pulled/pushed at the same time.

Initial gate setup

$ hg clone ssh:// myrepo
$ cd myrepo/usr
$ hg clone ssh://

Syncing with onnv-gate

$ cd path/to/myrepo
$ hg fpull

You may find this a little slow as it has to traverse the whole workspace looking for nested repositories so it can build the definition of the forest. This can be speeded up using the "fsnap" command to create a snapshot file. Or you can create one by hand, that may look similar to this:

root = .
revision = tip
path.default = ssh://

root = usr/closed
revision = tip
path.default = ssh://

To use the snapshot file we run fpull like this:

$ hg fpull --snapfile /path/to/mysnapfile

ONNV-gate push rules

The rules for pushing to the onnv-gate when a single set of fixes needs to span the usr/src and usr/closed trees is that usr/closed must be pushed first. This basically means that you should NOT use the forest extension for pushing. However the number of people that this impacts is very small most developers just need an up to date usr/closed for building.

For this reason I'm not showing how to push with the forest extension here.

Tuesday Feb 19, 2008

Mercurial Links

A few hopefully helpful links for OpenSolaris/JDK developers in the transition to mercurial (hg).

Friday Jan 04, 2008

Migrating a Teamware workspace to hosted Mercurial

Casper just asked me: "How do you put your own project workspace on So I wrote up email describing how I do it. Since I thought it might be useful I've included a slightly reworded version of it here.

It has to be in either Mercurial or SubVersion. If it is a project targeting the ONNV consolidation then Mercurial is the choice.

First create a local clone of the Mercurial onnv-gate like this:

    $ hg clone ssh:// myproject

Make sure your Teamware gate is at the same point. Now do a 'wx backup' of your teamware workspace.

Untar the ??.clear.tar file from the wx backup directory into the myproject directory.

Check this still builds - it should but you will need to get the closed-bins tar file that match your clone of onnv-gate since you don't have usr/closed.

If it all built find commit this to your local repository

$ hg commit

You now need to create a repository on to host this. In your project page there is an "SCM Management" link that is shown only to project leads. Click that. On the left hand nav-column there will then be a link "Add Repository". Fill in the form.

The Anonymous here means allow anyone to pull from the repository, if you don't tick that then only people with an account with loaded ssh keys can do a pull (I generally allow it as do most projects I believe). Project leads can always do a push, and you can delegate that to people who are listed as observers too.

The name you give is tagged on the end of your project URL. So if you say "gate" you will end up with:


The notification email gets every push message, so choose wisely what you set this too. Some projects use a dedicated -notify@ alias others just use their -discuss@ alias.

You are now ready to push your changes so lets configure your local copy of your Mercurial repository with the paths. Add the following to the .hg/hgrc file in your myproject dir:


Now lets do the push:

$ hg push

You now have a populated repository on To do a resync with onnv-gate you do something like this:

# Make sure you are in sync with the fgap project gate
$ hg pull
# Merge if needed
$ hg merge

# Now pull in the onnv-gate changes
# if you want a specific build you can say -r onnv_80 after the pull
# Note this uses the path alias we defined above to avoid using the full URL
$ hg pull onnv-gate
$ hg merge
$ hg commit
$ hg push

Hope this helps.

Note that for all this push/pull to work as your user you need to have your ssh pubkey uploaded for If you have ever voted you have done that already.

Friday Jan 05, 2007

Updated webrev with Mercurial support

I've been updating my draft of the support for the Mercurial SCM system in the OpenSolaris webrev tool.  My latest version is available as webrev output generated by itself here.  This version is sync'ed up with Dan Price's recent changes.

Darren Moffat-Oracle


« July 2016