SVN commit politics

Since code commit implies the code quality and stability, the ANKOS project
define some politics for new developers and ANKOS official members.

First, if you are new on ANKOS project, probably you won't have permission
on doing commits. So, your code contribution must be approved by some ANKOS
developer members before inserting it in the main development line. As soon
as your aproved contributions quantity increases, you may become an ANKOS
developer member, and your code can be directly commited.

SVN best practices

Commiting well defined changesets

Since your commit will create a new version number, is hardly recommended
that you only commit well defined changesets. It means that you must commits
code that achieved a single purpose: fixing a specific bug, adding a new
feature, etc.

Linking bugs on your commits

Always try to link your commit to the issues ID in the tracker database.
Also, when closing the issue on the tracker, try to put the revision number
that resolved the issue. Note that it is possible only if you follow
the Commiting well defined changesets strictly.

Track merges manually

Before committing the result of a merge, be sure to write a well descriptive
log message that explains what was merged, something like:
Merged revisions 3490:4120 of /branches/foobranch to /trunk.

Branching

The politcs for ANKOS source branches is Branch-When-Needed system. It
menas that developers commit their day-to-day work on /trunk. And, only
when it makes sense, is created a branch.

Tagging

The politics for ANKOS source tagging follow the O3S Process. It
means that is created a release for the users in each interaction phase.