These are some rules for checking in code.

1) Make SMALL, incremental improvements.
  -- don't check in incomplete or knowingly broken changes, unless
     you need to change computers for some reason... in this case,
     indicate in your commit message that it is broken.

  -- don't change more than one change in each commit

  -- use a meaningful commit message summarizing exactly what
     you did in that change.  this is less important for paper
     writing, more important for code development.

  -- this means don't indent whitespace or delete commented out code
     in the same revision as other changes.

The rationale behind this is that we can more easily locate where
problems lie, if and when they arise, by doing a binary search on the
commit history (we did this last night to find the revision where if
stmts broke).  Basically, commits, branches and repository versions
are super cheap, and developer time is expensive.

2) The trunk is ULTRA stable.
  -- thoroughly test everything AFTER you merge and BEFORE you commit

  -- it is probably worth updating your sandbox to the latest trunk
     revision and committing there, before trying to merge to the trunk.

  -- in our case, at all times, the existing regression tests for pnfg
     must work (pnfg/fulltest.sh).  testing the generated .nfg files 
     must also work (nfg/fulltest.sh), if a solution has been written.
     you are encouraged to write new tests and solutions.

  -- the commit history for the trunk is important, it should not be
     sloppy and it should be easy to follow exactly what's going on.
     that is the primary reason we are fixing things on broken-trunk
     at the moment.

3) For EVERY new language feature, introduce MULTIPLE regression tests.
  -- every time the grammar is changed, a new testcase for each possible
     usage of the new syntax needs to be written.

  -- we can make subdirectories in pnfg/examples for the features, so
     that they don't pollute the real games in examples.