Nomad PIM
Commit Rules
As of December 12th, 2009, the development of Nomad PIM has been discontinued

General Rules

These rules apply for all commit operations.

  1. Format the modified files, organize import statements and sort the members.
  2. Always update before you commit to ensure that your local workspace is up-to-date.
  3. The commit messages should look like this, to provide traceability (example for a commit related to two tracker items): 
    #123456 Description of tracker item 123456 from the tracker
more about the intentions and changes of the commit, perhaps
in more than one additional line

#567890 Description of tracker item 567890 from the tracker
more information about this second tracker item worked on in
the commit

Rules for committing to the trunk

These rules apply only when working on the trunk. All commits to the trunk are reviewed. However, if a task is rather large, it should be considered to do the changes in a separate branch that is merged back into the trunk later on. The commit rules for branches may differ from these rules and should be separately agreed on for each branch.

  1. No commit must break the compilation and/or the unit tests. If you commit a test that makes a bug visible, deactivate it until the fix is available.
  2. When doing a commit, think of the reviewer as recipient, both when writing the commit message and selecting the content for the commit.
  3. Before committing half-finished classes to the repository, think about the date at which you will probably finish the work on these classes, especially when you are working on cleanup tasks. If it is only a few hours or a day away, you might consider to delay your commit until then.
  4. Try to commit only the work of one main task at a time. If there are a few minor tasks, as it may be the case when you perform cleanup work on the fly, you should add all corresponding tracker IDs to the commit message. For cleanup work, it is okay to work on more than one main tracker item.
  5. When committing a change that crosses several plug-ins, commit it in one commit by selecting all the affected plug-ins in the package explorer and then select team/commit in the context menu, for example. You can also commit changes across several plug-ins in the team synchronization perspective by synchronizing multiple projects and then committing all changes. In order to prevent an automatic splitting of the commit, the use of Subversive is recommended.