[pisa-src] r1153 - docs/HACKING

From: Thomas Jansen <mithi@xxxxxxxxx>
To: pisa-src@xxxxxxxxxxxxx
Date: Thu, 15 Oct 2009 11:53:29 +0200
Author: tjansen
Date: Thu Oct 15 11:53:29 2009
New Revision: 1153

Log:
Updated the HACKING guidelines for people working with our SVN repository.

Modified:
   docs/HACKING

Modified: docs/HACKING
==============================================================================
--- docs/HACKING        Wed Oct 14 17:22:24 2009        (r1152)
+++ docs/HACKING        Thu Oct 15 11:53:29 2009        (r1153)
@@ -1,9 +1,10 @@
-This readme should contain a detailed desctiption how to set up the system you 
are about to create.
+This readme should contain a detailed description how to set up the system you
+are about to create.
 
 Some basic rules for coding:
 
 SVN RULES
-==================
+=========
 
 - Only check in code that compiles and runs (see TESTING)
 
@@ -12,17 +13,36 @@
 - "Some bugfixes in ab.c" is NOT a sensible message
 
 - Do not check in binarys (no *.o, *.a, *.pdf, *. ...) of files for which 
-  the source  is contained in the repository
+  the source is contained in the repository. You instruct SVN to ignore such
+  files in status listings by editing the directory properties with
+  "svn propedit svn:ignore $DIRECTORY"
+
+- Checkins which don't compile must be fixed immediately (Penalty for not
+  fixing it within 2 hours is one RICE CAKE for the group)
+
+- Split commits into chunks of reasonable size. Do not commit changes related
+  to different topics in the same commit. Splitting refers to functional and
+  logical dependencies, not committing file after file when the changes are
+  related.
+
+- Be sure to doublecheck every change before you commit. Use "svn st" to get a
+  list of modified files most importantly "svn diff|less" to see all changes.
+  The first makes sure you don't forget to put new files under SVN control.
+  Remember that SVN is relative to the current working directory. Changes in
+  sibling or parent directories are not listed and not committed, so be sure
+  to cd to trunk if you changed things in several directories that you want to
+  commit simultaneously.
+  The second command let's you view all your changes as unified diffs. Go
+  through all of them to spot typos, debug lines you forgot to remove,
+  formatting errors, lines that you removed accidentally and things that
+  should be listed, but aren't.
 
-- Checkins which don't compile must be fixed immediately (Penalty for not 
fixing
-  it within 2 hours is one RICE CAKE for the group)
- 
 
 TESTING
 =======
 
-- Write a test program for your code that checks all relevant cases. That will 
save
-  you and other much time.
+- Write a test program for your code that checks all relevant cases. That will
+  save you and other much time.
 
 - Put effort into writing that program (document well, structure well)
   -> Other people might depend on these tests
@@ -38,7 +58,6 @@
 - Comment your makefile rule
 
 
-
 CODING CONVENTIONS
 ==================
 
@@ -46,8 +65,7 @@
 
 - There should be an doxygen header for EVERY function (see DOCUMENTATION)
 
-- Don't invent your own coding style. It will give the code an
-  ununified look.
+- Don't invent your own coding style. It will give the code an ununified look.
 
 - Use under_scores
 
@@ -55,7 +73,8 @@
 
 - Use global variables only with GOOD reason
  
-- Use 4 spaces as TAB in userspace and 8 spaces ad TAB in kernelspace!
+- Use 4 spaces as TAB in userspace and 8 spaces as TAB in kernelspace! This
+  refers to the TAB width, not to replacing TABs with space characters.
 
 - USE ASCII encoding! No fancy symbols like: ����......
 
@@ -63,6 +82,7 @@
   userspace code. This rule may be relaxed in the kernel code because
   the space is very limited due to the 8 character indentation.
 
+
 DOCUMENTATION
 =============
 
@@ -97,4 +117,3 @@
        /*! \todo
         * Make contents for this function!!!
         */
-
[pisa-src] r1153 - docs/HACKING

Other related posts:
