SVN Guidelines
Here some guidelines for developer who have write access to SVN. These guidelines might change over time, esp. if we get more developers working at the same time, and if we get closer to a release. ATM SVN is considered to be really unstable (though see below for guidelines). Some of the recommendations are done based on the fact that there are not many developers (about 3 actually involved in coding), but many people playtesting.
- Subscribe to the stk-development list (see Contact_us). Developers usually post what they are working on here, so that the likelyhood of conflicts can be decreased. Additionally, known bugs are posted here, too.
- It might be worth subscribing to the stk-commit email list, see Contact_us. All commit message are automatically sent to this address, so you will always be aware of what is happening, and if your work interferes with what other pepople are doing.
- The SVN version should always compile. While it's not possible to test on all platforms, do your best to write portable code. Other developers and testers will usually quickly point out (and fix) any problems.
- Commit frequently. Frequent commits have the advantage that they act as a backup (some people have lost their work because of a harddrive crash), and they make time consuming conflicts less likely.
- Test your commits to make sure they do what they are supposed to do. It might not possible to do very thorough tests (e.g. a single change of a physics parameters means that you would have to race each kart - potentially on each course), so listen for bug reports from tester. it might be worth even asking for specific feedback from testers.
- Make sure that at least normal racing always works. This is the functionality other developers most likely need. If there is a known minor problem (e.g. 'restarting' might not work), post this to the mailing list to avoid unnecessary bug reports, or put it in the bug tracker if you are not going to fix it quickly. These kind of minor known bugs are acceptable while we consider SVN really unstable. When getting closer to a commit all minor bugs should be fixed before committing.
- Try to include all changes for a single feature in one commit (i.e. don't commit each file separately, and try not to mix several features in one commit - though the latter is acceptable since it might be a lot of work to split a change set into different commits).
- Do not use locking. SVN is usually doing a good job in automatically merging changes in, and it allows for a much more parallel development.