Subversion Trac rules tutorial

A guide that I worte for company staff to follow.

SVN:

• Use TortoiseSVN client.
• Our subversion has the usual trunk/branches/tags layout. Never develop on trunk! Do your part in branches and merge it back to trunk.
• Recommended check in frequency is every hour! Comment is a MUST.
• Exclude unnecessary files that are not required in compile. (eg, obj, exe) Pay attention to check-in huge files that can’t be re-versioned!
• ONLY merge changes that can be compiled and tested into truck. ( and reviewed! Will have detailed discussion about this.)
• Commit changes as a single logical change set for one purpose. Thus all code changes for a single bug fix or enhancement should be checked-in together. This allows one to better follow the history log of changes.
• Check-in code at the directory level and all changed files, recursively in the directory and subdirectories will be checked in together.
• Using Trac integrated with Subversion, refer to the Trac ticket in the Subversion check-in comment using a "#" in front of the Trac ticket number (eg. #65). This generates a hyperlink when the Subversion logs are viewed in Trac.
• The "tags" branches are NOT to be used as working branches but are snapshots of an existing branch. The "tags" are for historical reference such as a release, well tested version or progress milestone.

Trac:

• Document project based information in Trac wiki. (eg, Anything that isn't obvious to fresh eyes gets documented on the Trac Wiki.)
• Spend at least 0.5 hour a day documenting on the Wiki. This should get placed in the "Documentation" category on the time-tracking software.
• Using Subversion integrated with Trac, refer to the Subversion specific revision in tickets using a “r” in front of the revision number (eg r103). This generates a hyperlink to view the source in Trac.