Please comply with these:

  1. Always write a commit-message (no exception). Write the whole commit-message in exactly 1 line (no linebreaks) and separate - if appropriate - single items with semi-colon ';'.
  2. Try to separate independent changes into several commits. Each coherent change one commit (there might be exceptions)

How to commit?

  • Check your modifications.
$ svn diff       # comfortable: svn diff | view -
$ svn status
  • Check if there are new revisions of files. Detect/prevent conflicts. (See the SVN Manual about resolving conflicts)
$ svn status -u
$ svn update
  • If everything seems to be fine, commit.
$ svn commit -m'commit message' [<files>]


Creating a new ticket

  • Summary: short description of the problem/bug/enhancement/task
  • Reporter: in most cases this is YOU
  • Description: detailed description. If the ticket describes a bug, try to add a section “Steps to reproduce” and always write on which revision the bug occurs.
  • Type: Is it a bug, an enhancement or a task?
  • Priority: most cases this should be left on the default value
  • Milestone: till when should the ticket be fixed? If it's not release/milestone related, leave this field blank. If it's not scheduled for a specific release/milestone, set milestone “Future”.
  • Component: select the appropriate component. If nothing fits, select “other”.
  • Version: in which released version does the problem occur? If the problem occurs in current development tree, select “trunk”.
  • Keywords: optionally, needs not to be filled
  • CC: not needed (yet)
  • Assign to: if you know that someone (including you) is currently working on this ticket or is going to work on this ticket, type in the developers name.

Closing tickets

  • set the appropriate solution
  • add a short description to field “comment”. If appropriate, add a reference to the changeset (with r123 or changeset:123).

About the code

Please comply with these:

  1. Try to be generous and verbose with comments.
  2. Coding style:
    • Use tabs for indention instead of spaces (tab-width = 8 spaces).
    • Curly brackets belong on their own line for statements. (valid for C++; for C-code put curly bracket in same line)
    • No spaces between round brackets and arguments. Arguments are separated by a space behind the comma.
    • Space between statement (e.g. if, while) and the following round bracket, but no space behind a function.
    • Pointer sign belongs to variable name (avoids things like this: int* a, b which in fact means int *a, b).
  3. For new source/header files use the docs/license_stub.txt header as template
  4. Important: Always save with UNIX line-endings (NOT MS-DOS line-endings)

Example code:

if (true)
	do_something();    // do something useful
	do_something(123, arg2, etc);
int *x, *y;
float* calc(float a, float b)
	return a + b;
class ExampleClass
	void setValue(int value);
	int getValue() const { return value; };
	int value;
	int flags;
void ExampleClass::setValue(int value)
	// this-pointer needed if same variable name in current scope
	this->value = value;
	// no this-pointer for members
	flags = 0x123;
switch (option)
case value1:
case value2:
Recent changes RSS feed Creative Commons License Donate Powered by PHP Valid XHTML 1.0 Valid CSS Driven by DokuWiki Get HoldingNuts at Fast, secure and Free Open Source software downloads