OpenSolaris

1. Project: SCM Migration Project
   1. Discussions
   2. Leaders
   3. Observers
   4. Files
   5. Gate Architecture
   6. Client-Side Hooks
   7. Testing
   8. Blogs
   9. Meetings

This page has notes about how the gate will interact with tools, users, hooks, etc. Feel free to add details.

Overview

The gate will be a standard Mercurial workspace. Developers will continue to use tools from SUNWonbld, as well as Mercurial (hg). Some existing SUNWonbld scripts will be replaced by Mercurial extensions (e.g., Cadmium).

The closed tree (usr/closed) will be a separate mercurial workspace.

The clone will be implemented as a separate workspace, as will the build snapshots, rather than as tags in a single workspace.

Mercurial has a hook API that supports commands (usually scripts) and Python functions. Details are available in Bryan O'Sullivan's Mercurial book.

Some Mercurial hooks can fire before an operation and prevent the operation from happening. We plan to use that mechanism to provide tighter enforcement of some policies (e.g., approved RTI, no new cstyle errors).

The current plan is for the ON gate to move to opensolaris.org as part of the transition to Mercurial. The alternative would be to have an intermediate milestone, where the gate is using Mercurial but is on the SWAN. The problem with that alternative is that it requires a second move, adding to the general churn and confusion in the ON developer community. And the gate will need to move off-SWAN to allow for external committers, anyway.

Having the gate on opensolaris.org means that the gate hooks cannot depend on SWAN services, including Bugster, the current WebRTI infrastructure, or NFS access to on-SWAN hosts.

The Clone

We definitely want to keep the clone concept—it provides a semi-stable reference point. But in Mercurial readers do not block writers, so we don't necessarily need to have a separate repo. We could just use a tag that is updated nightly. Still, we and our tools already understand the "separate repo" approach, so that's what we're going with to start.

Hooks

The gate will have a standard set of hooks. Some will be for enforcement, some will be to kick off additional activities (e.g., after a putback).

We may predefine hooks for child workspaces. Since developers can disable them, we can't rely on them for policy enforcement.

Until Mercurial issue 706 is resolved, hooks should not write to stdout.

Testing

The current plan seems to be set up the system tijuana.opensolaris.org as a shadow gate system. There may still be configuration work to do, like making sure it has a recent Solaris build, setting up test accounts, etc.