Mercurial Repositories

The NetBeans source is organized into Mercurial repositories. Currently the interesting ones are:

• The Mercurial main repository. Now and in the future, new functionality that is reasonably stable (does not break anything else) goes into the trunk. This code is used to make regular daily development builds.
• Milestone branches. Periodically between major release a build is made which has been vetted for quality. Each such milestone build gets its own Mercurial repository, which usually diverges from the trunk in only a few files which needed to be patched to fix high-impact bugs.

Older versions of NetBeans are kept in CVS (on cvs.netbeans.org) with the following branch names:

• NetBeans Release 6.0: the CVS branch release60 holds sources for the NetBeans 6.0 stable release.
• NetBeans Release 5.5: the CVS branch release55 holds sources for the NetBeans 5.5 stable release.
• NetBeans Release 5.0: the CVS branch release41 holds sources for the NetBeans 5.0 stable release.
• NetBeans Release 4.1: the CVS branch release41 holds sources for the NetBeans 4.1 stable release.
• NetBeans Release 4.0: the CVS branch release40 holds sources for the NetBeans 4.0 stable release.
• NetBeans Release 3.6: the CVS branch release36 holds sources for the NetBeans 3.6 stable release.
• NetBeans Release 3.5: the CVS branch release35 holds sources for the NetBeans 3.5 stable release.
• NetBeans Release 3.4.1: the CVS branch release341 holds sources for the NetBeans 3.4.1 stable release.
• NetBeans Release 3.4: the CVS branch release34 holds sources for the NetBeans 3.4 stable release.
• Sun ONE Studio (formerly Forte for Java) 4.0: the CVS branch orion_fcs is used for Sun's Sun ONE Studio (Forte for Java) Community Edition 4.0. This branch is almost identical to release33 (below) for most modules. sierra is used for 4.1.
• NetBeans Release 3.3.x: the CVS branch release33 holds sources for the NetBeans 3.3.x stable releases.
• Sun's Forte for Java 3.0: the CVS branch pilsen holds sources for Sun's Forte for Java Community Edition 3.0. For most modules, this is based off of NetBeans Release 3.2 (below) with no or very limited changes. For web, j2eeserver, and logger modules this branch contains distinct lines of development.
• NetBeans Release 3.2.x: the CVS branch release32 holds sources for the NetBeans 3.2 and 3.2.1 releases.
• NetBeans Release 3.1: the CVS branch release31 holds sources for the 3.1 release of NetBeans.
• NetBeans Release 3.0: the CVS branch stable30 holds the source for a former stable NetBeans release. It is based off of the postfcs branch, below.
• Sun's "Boston" branch: the CVS branch boston was reserved for stabilization of the FFJ 2.0 release.
• Sun's post-FCS branch: the CVS branch postfcs is reserved for the code line used for the 1.0.x versions of FFJ, including a number of module updates.
• gandalf branch represents the 1.0 released IDE, pre-updates.

General principles of using branches:

• The main repository (or trunk) should be used for ongoing development of the IDE. Code checked into the trunk should be reasonably stable (i.e. it should compile and at runtime should not cause the IDE to be unusable, especially in terms of interfering with other modules or components of the IDE). It need not be perfect.
• Branches may be created by developers for purposes of checkpointing experimental code which is not expected to be stable for a long period of time. These branches may be created as needed, possibly on a per-module basis. Module pages should document branches they are using.
• Stabilization branches, which should be documented here, and are used to stabilize the entire IDE in preparation for an official release of some sort. Commits to these branches should be to fix important bugs, not to add new functionality; and such bugfixes should be also applied immediately to the trunk (assuming they apply). The NetBeans team may create such branches and other parties who are interested in producing a release may also create them. Since stabilization branches exist in the public repository, anyone can take advantage of testing and fixes done on these branches.

If you get access to the Mercurial server for pushes, please make sure you understand what the different branches are being used for, and check in onto the appropriate branch, with an appropriate amount of pre-checkin testing.

Directory Structure

The NetBeans Mercurial repository is organized by "modules". Refer to the modules list for a complete list of these modules.

Within a module, there can be various files and subdirectories. There are certain special naming conventions used mainly to increase clarity and familiarity of the source organization. A module may have any of the following subcomponents:

• src/ - the Java source code for a module. This is arranged in a package hierarchy. For example, the Form Editor module contains a source file in the path form/src/org/netbeans/modules/form/FormEditorModule.java.
• manifest.mf - the JAR manifest for the module. It contains special attributes informing the IDE of what the module contains, as well as metainformation such as name and version.
• javahelp/ - JavaHelp files and HTML for online documentation for the module. In a package hierarchy. This may be placed inside the module JAR, or in the docs/ directory in an IDE installation. For example, crosscompile/javahelp/org/netbeans/modules/crosscompile/CCHelpSet.hs.
• build.xml - Ant-based build script for the module.
• test/ - test suites, probably using XTest.
• release/ - files to be placed in the IDE's installation directory, rather than in the module JAR itself. Subdirectories should match the installation structure. For example, form/release/beans/TimerBean.jar. Only used for Common Development and Distribution License (CDDL) v1.0 and the GNU General Public License (GPL) v2 covered files.
• external/ - third-party files not covered by the Common Development and Distribution License.
• apichanges.xml - list of API changes made to the module, in a standardized XML format
• src/.../package.html and src/.../doc-files/*.html - documentation for the API.
• arch.xml - architectural descriptions of a module in a standardized XML questionnaire format

More standard names can of course be added if there is a conventional use for them. The file harness/README in the IDE distribution has some more details on module project organization.