DNA CVS Policy

  1. Principles
  1. Guidelines

Commits will be taken by all developers. Broken code will be broken for everybody. CVS does allow fairly easy recovery but take care so as to avoid the need.

Compile and correct code before committing. Ensure new files that compilation requires are also committed. Be especially careful if you change the build system.

Avoid things like "I'm not if this is right but it works for me". If solutions cannot be found discuss with other developers.

Start DNA and make sure the code behaves as desired. Run automated tests.

Use CVS commands to check changes before committing. Takes messages about conflicts, patches etc seriously. The "cvs diff" command will tell you what you will be committing. Check it's what you really intend.

These changes will affect other developers. Reviewing these changes should avoid problems and conflict.

Mixing such changes make it very difficult to see real changes. Commit format changes separately and ensure they are logged as such.

Log messages should ideally be understandable to someone who only sees the log. Try to put log messages only in those files really affected by the changes described. Put in all important information which cannot be seen from the diff.

Fixes to bugs in the developers branch should be applied to the trunk is applicable.

Even if these changes look trivial they may break other code. Announcing these before hand gives the opportunity for developers to raise concerns. Changes internal to a single DNA system part need not be announced in advance (see DNA responsibility page). However, changes that span different sub parts like changes to the XML definitions should be anounced beforehand.

These changes cause unnecessary conflicts when merging branches and don't contain any information not in the repository anyway. The Id keyword can be useful when used in the header of a file, however it's up to the responsible of the DNA part of the code to decide if the Id keyword is allowed or not.

CVS can commit more than one file at a time. Commit all related changes in multiple files at one time, even if they span multiple directories. For example, if an XML definition has been changed, commit the XSD file changes together with the changes to the Java or Python code affected by the definition change.