Source code
Checking out the code (authentication required)
Our code is also available for viewing online here
; you can log in there to access various code statistics, colored diffs, email and/or RSS notifications for checkins and other goodies provided by FishEye.
We employ a typical Subversion layout using /<project>/trunk, /<project>/branches and /<project>/tags. Currently there are two projects, dso and dev-tools. More details about branching and merging can be found here.
If you use Eclipse, please see this page about getting it set up the first time. Information about the code layout and how to build it is located here.
Coding style
There are a handful of legal and formatting conventions used in Terracotta source code. If you are a source code contributor please read the Coding style page for more information.
Checking in
Before committing a change, developers are expected to a) write tests for the features/functionality they create and b) run the full test suite before checking in changes to ensure that /dso/trunk is always in good health. If you are going to work on a big feature or have to work on several things at once, it is highly recommended to work in a branch.
The Terracotta Subversion repository requires that certain properties are set on newly-added files based on file extension. The presence of these properties is enforced by a Subversion pre-commit hook script that will reject any commits that contain new files without the appropriate properties.
The required properties are as follows.
| Property Name |
Property Value |
File Types |
| svn:eol-style |
native |
Most plain text files, such as Java source files |
| svn:mime-type |
image/png |
PNG image files (*.png) |
| svn:mime-type |
image/jpeg |
JPEG image files (*.jpg) |
| svn:mime-type |
image/gif |
GIF image files (*.gif) |
The best way to ensure that newly-added files have the required properties is to use the Subversion config file located in the Terracotta Subversion repository:
This config file uses Subversion's "auto-props" feature to automatically add the required properties to newly-added files.
To use this configuration file, you must save it in your Subversion configuration directory. On UNIX-like systems, this is the .subversion directory in your home directory. On Windows the location will depend on which client you are using. If you're using the native win32 binaries, you can find the subversion files under C:/Documents and Settings/%USERNAME%/Application Data/Subversion. If you're using the Cygwin version of subversion, the .subversion directory will be in your home directory.
Commit Messages
All Subversion commits must have a meaningful log message that meets the following requirements:
- Description: A description of the changes made for this commit, which should focus on the "why" for the change since the "how" and the "what" are in the diff for the commit.
- JIRA: If the commit is associated with a JIRA issue, the log message should begin with the JIRA issue number, e.g.
- Merge info: If the commit is for a merge operation, merge information must be included. The required merge information includes the revision numbers that were merged and the source of the merge (e.g. "trunk" or "2.5 branch"). For example:
Merged revisions 101:107 from trunk into 2.5 branch
- If the commit is for a bug fix, consider including information on how the fix was tested.
NOTE: Never include customer information in commit messages.
Rolling back change sets
If you cancel out a change in Subversion by creating a new "undo" change set, please send the branch name (or /trunk) and a list of the change set numbers that cancel each other out to the developer mailing list. Developers using svnmerge.py to manage their branches can choose to block these changes when updating from your branch (or /trunk most likely) and avoid merge hell when keeping their own branches up to date:
$ <path to dev-tools>/subversion/svnmerge.py block -r<revisions>
$ svn commit -F svnmerge-commit-message.txt
$ rm svnmerge-commit-message.txt
Those changes will thereafter be ignored each time svnmerge.py merge is run.
