Probably obsolete. See HgParallelTeamIntegration

Mercurial Build Infrastructure Plan

NetBeans are likely to switch to distributed source control system Mercurial for development of versions to follow 6.0. The distributed nature of this source control system allows us to improve development workflow in a way that was hard to achieve with CVS. This document proposes new development model that shall return the NetBeans project so desired Fitness lost during the major changes done during development of 6.0.



  • the main NetBeans Hg repository has to be always buildable
  • allow cooperation between team members
  • team = any group of people that share the same view of the source code - e.g. teams working on the same part of the source base, those working on same feature, etc.
  • distribute broken_builds notifications only to teams that caused the failure
  • prevent regressions


The basic idea is that we would have one master repository where the push backs could be done only in automated way. No regular developer would have the privilege to push her changes directly to the master repository. All the changes would be required to go through the automated system and tests before they end up in the master repository.

File:Mercurial Build Model Development Work Flow

The image above show the simplified way how the distributed development environment could work for one single team. The simplification I used that I'm assuming that we'll have only one master repository and the picture also shows only one developer/team. There is no reason why it can't be extended but it would only add more complexity to the basic idea.

Every developer should have its own working clone of the master repository where she is doing all the developer work. After she decides that the quality of code is good enough she may push her changes to her team preintegration repository. This repository would be setup to trigger the fast continuous build which takes the binaries from previous build and only rebuilds the changed clusters. This fast continuous build should work as a first phase filter for compile time errors. The integration to the preintegration repository would also trigger the full CB to ensure that all the dependencies are still OK (the full CB will clone the Team repository and update from the main repository). This build would trigger full tests suite using produced binaries. After the successful completion of those two builds the automated push to the master repository could be done.

Alternative using test integration repository

The above scheme may run into trouble since the preintegration area cannot push to master without doing a merge first, which could then fail.

Instead, let us assume have different people pushing changes to various team repos, which only get integrated into main occasionally, after some kind of sanity checking. This is good for stability and for reducing push contention (and thus extraneous merges). But it is not good for QE, who really would like to verify bugs in an single build as soon as possible. And it is good to know right away if changes in different team repos will not work together.

So I suggest having an integration test repository, which should be hidden inside a continuous builder workspace to make sure no one tries to pull from it (as it would contain automatically generated changesets). It would go through the following cycle:

conflicts = {}
  rm -rf .
  hg clone main-golden .
  build = false
  for team in [CoreMainMolden,WebteamMainMolden,....]:
    hg pull $team
    if $?:
      # skip this repo in case of network failure
    hg up
    unless $?:
      # team repo is superset of main-golden, fine
      build = true
    HGMERGE=merge hg merge
    if $?:
      hg ci -m "merged from $team"
      build = true
      if conflicts[$team]:
        conflicts[$team] = false
        send_mail "merge conflict from $team resolved"
      # undo effects of pull & merge
      hg rollback
      hg up -C
      unless conflicts[$team]:
        conflicts[$team] = true
        send_mail "got conflict merging changes from $team"
  if $build:
    # wait e.g. 10min to reduce network traffic
    sleep 600

Here are the scenarios this algorithm would handle:

  1. Nothing happening in any team repos.
 OK, wait a while before checking again.
  1. Changes made in one or more team repos but not in overlapping files.
 OK, get the new files (like 'cvs up') and try to do a build;
 report any build failures to the usual subscribers.
  1. Changes made in two or more team repos to the same file
 (which have not yet been merged by developers).
 OK, try to merge; if it seems to succeed (no line-level conflicts),
 run a build to see if it's really OK.
  1. Changes which conflict (made to the same or nearby lines).
 Skip over the pull which would introduce the conflict,
 and warn people about it (just the first time it happens).
 Could wait to be resolved until the next general team push,
 or could be resolved immediately in one of the conflicting team repos
 by pulling from the other team's repo and carefully merging.
  1. Multiple heads in a team repo. No idea what to merge; will probably be treated like #4.

Basically, within 10 min + time to pull + time to do a build, say an hour in total, of when you push some changes to your team repo, you will either

  1. know that your changes break compilation of some apparently unrelated part of the product,
  2. be able to point QE to a build with your changes that they can verify.

I think it may still be useful to have continuous builds running out of team repositories, as these will tell you whether the team repos in isolation are OK, which is valuable information for different purposes. If those team builds also published team golden repos, you could be more sophisticated and try to integrate only them, avoiding the noise of having a general integration build failure just because someone on one team checked in an uncompilable file.

Not logged in. Log in, Register

By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo