CommitRules

Commit Rules: Pushing To The NetBeans Mercurial Repository

Having push access to the NetBeans Mercurial repository is a privilege but also a responsibility: responsibility to the quality of the code and responsibility to other people working on NetBeans. In order to ensure that the quality of the code base is high and that you will not disturb anybody else's work, here are a few guidelines that will help you to validate your changesets before you push them into the NetBeans Mercurial repository.

1. Do Clean and Build

When your modifications are ready to be pushed do a clean build to make sure that it does not negatively influence other modules. Invoke
       ant clean
to build the artifacts (classfiles, etc.)
       ant
to compile the NetBeans IDE.

2. Run commit validation test suite

Execute commit validation test suite which is designed to test the basic functionality of NetBeans and shall affirm you that your integration is not completely broken. Execute
       ant commit-validation
Of course no test shall fail otherwise there is something wrong - probably with your integration. At the end it is printed out summary information about pass ratio of the suite. There is also provided a link to HTML presentation of the results. If something fails, you should follow this link and check error messages to determine what is wrong with your build.

3. Run tests from changed module(s)

Execute unit tests that might be influenced by your changes. For example when committing into the form module its test shall be run by
       ant -f form/build.xml test
and shall not fail.

4. Ready for integration

If the IDE compiles, tests pass you are ready for integration. Check what you have changed by evaluating the output of
       hg out -p
and if the output really contains what you have modified do
       hg push

Tips and tricks

  • If you participate in development, you should be subscribed to broken_builds@netbeans.org. Failures in daily builds as well as continuous builds are announced there and if your integration breaks something, you can react quickly. If you are going to fix such a problem please reply to the broken_build message, so others know that it is being solved.
  • Usually you commit changes that have an entry in the Bugzilla tracker (bug, task, enhancement). In this case mention the issue number in the commit message. For example you write
       hg ci -m '#31043: Fixing the screen resolution'
and include the changeset hash of the commit in the description field when resolving the issue. Then it is possible to find out more about the commit in the Bugzilla and it is possible to find the sources that were modified to resolve the issue.

Common mistakes

  • Do not check in debug code that depends on a modified API with something made public that isn't. Solution: Always do a sanity diff.
  • Do not check in a class that also contains a change that's part of a different bug fix. Solution: Always do a sanity diff
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