"Seegrid will be due for a migration to confluence on the 1st of August. Any update on or after the 1st of August will NOT be migrated"

Procedure for committing to the GeoTools and GeoServer subversion repositories

Branch maintenance

Never commit without module maintainer permission

  • Failure to seek permission before committing to someone else's module may result in the revocation of your commit access by the Project Committee.
  • Submit a patch via a Codehaus Jira issue and assign the patch to a module maintainer for review.
  • The maintainer may commit the patch themselves.
  • The maintainer may give you permission to commit the patch.
  • Maintainers might be identified in the module pom, but these are often out of date, so subversion logs are often a sufficient substitute.
  • When in doubt, ask.

Conform to project rules

  • Conform to project coding conventions.
  • Follow project rules on module creation and promotion.
  • These are found in the developer guides.
  • When in doubt, ask.

The build

  • "The build" refers to the continuous integration builds of GeoTools and GeoServer.
  • If these builds fail, "the build is broken".
  • If you cause one of these builds to fail, "you have broken the build".
  • Opengeo Hudson:
    • http://hudson.opengeo.org/hudson/
    • All projects and branches are built separately.
    • This is the main continuous integration for the GeoTools and GeoServer communities.
    • If you break this build and do not fix it, core developers will fix it for you by reverting your changes or kicking your module out of the build, without notice. This is a Bad Thing. Do Not Let This Happen.
    • If you make a habit of breaking the build, the Project Committee may revoke your commit access.
  • Computational Geoscience buildbot for GeoServer trunk:

Update before local build

  • You must update before starting local builds:
    • svn update
  • Updating increases your chances of detecting conflicts or incompatibilities with other developer's commits.
  • Do not update if the build is broken.

Local build before commit

  • To ensure you do not break the build, make a clean local build before any commit.
  • You will need a separate local build for trunk and stable.
  • You will need a local build for GeoTools and then GeoServer.
  • If you change GeoTools, you must rebuild GeoServer to ensure your changes do not break it.
  • Yes, this means that a GeoTools change backported to stable will require four (4) builds before committing.
  • See GeoserverMaven for more.

Do not commit if the build is broken

  • Do not commit if the build is broken.
  • If you commit when the build is broken:
    • New failures may be introduced.
    • It becomes increasingly difficult to identify the changes responsible for the failure.
    • Continuous integration is lost.
    • Chaos ensues.

Commit log messages to contain Codehaus Jira issue

  • Every commit must contain a log message that describes the commit and includes the Codehaus Jira issue (if there is one).
  • Do not include issues from non-public Jira instances in commit logs.
  • For example:
    • svn commit -m "GEOT-3143: FeatureTypes.getAncestors will not terminate if a FeatureType has a getSuper() that is not also a FeatureType"

Codehaus Jira issue to record commit revision

Do not break the build

  • Do not break the build.
  • If you do break the build, fix it.
    • This means no commits just before you go home.
    • Hang around long enough to fix it if you break it.
Topic revision: r2 - 15 Oct 2010, UnknownUser
 

Current license: All material on this collaboration platform is licensed under a Creative Commons Attribution 3.0 Australia Licence (CC BY 3.0).