| This_line_is_for_vim_user_only vim: sw=12 ts=12 Version Control Policy 0. Brief This file is about the version control policy of our software team. Since svn will be used as the primary version control software here, most technical method will be based on that. Please check the 'Subversion Guidance' for the necessary knowledge. Generally speaking, version control policy is based on the whole team policy. Some principles will be mentioned here, but they are not, and should not be meant to limit the creativity of any team member. It is just for avoiding any trouble that may cause by irregular behaviors. 1. Server Setup 1.1. MULTIPLE repositories structure will be used on svn server. 1.2. Principle of repository dividing is based on: 1.2.1. MAJOR project - one repository holds one 'major' project, which may be a product, an isolated libaray, an assistant toolkit, etc; 1.2.2. BACKUP policy - how often the repository / major project should be backuped. 1.3. All repositories share the SAME password / authorization setup file. 1.3.1. Anonymous login is NOT allowed. 1.3.2. Authorization is managed by GROUPS, and granted by DIRECTORIES. 2. Repository Setup 2.1. Repository is accessed by given name, such as svn://HOSTID/PROJECT_NAME. 2.2. One repository may hold several 'minor' projects; a minor project (or an stand alone module) should: 2.2.1. Have its own TARGET, so that it should provide some API classes / functions; 2.2.2. Be able to be COMPILED, TESTED, and PUBLISHED seperately. 2.3. TTB structure is used. 2.3.1. What is TTB: trunk, branches, and tags: 2.3.1.1. Trunk: 'main branch' of the project; 2.3.1.2. Branches: 'sub branches' of the project, which is for multiple purposes (check chapters below); 2.3.1.3. Tags: LABELS or RELEASES of the project, which should be treated read-only. 2.3.2. Suggested layout should be: root/MINOR_PROJECT_1/trunk root/MINOR_PROJECT_1/branches root/MINOR_PROJECT_1/tags root/MINOR_PROJECT_2/trunk root/MINOR_PROJECT_2/branches root/MINOR_PROJECT_2/tags ... 2.3.3. If a project is imported and does not use TTB structure at first, an alternate layout may be: root/trunk/MINOR_PROJECT_1 root/trunk/MINOR_PROJECT_2 ... root/branches/MINOR_PROJECT_1 root/branches/MINOR_PROJECT_2 ... root/tags/MINOR_PROJECT_1 root/tags/MINOR_PROJECT_2 ... The disadvantage of this layout is, project2 must be released with project1 together, even if it's not been updated as frequently as project1. So it is not suggested. 3. Getting Started 3.1. Repository setup: 3.1.1. Creating repository; 3.1.2. Setting authorization; 3.1.3. Setting hooks for maintenance (backup, etc); 3.2. First import (usually done by administrator). Depending on actual status, at first the project may be: 3.2.1. PLANNING: with planning documents or limited source (not able to be built) only; 3.2.2. PRE-ALPHA: with limited build and under internal test; 3.2.3. ALPHA: with initial build and under QA's test; 3.2.4. BETA: with initial release and under customer's or public test; 3.2.5. PRODUCTION: with stable release, no critical issues (new feature may under planning); 3.2.6. MATURE: fully tested and used for a certain (e.g. 3 months) and without any knowing issues, or all knowing issues are waived already. 3.3. Users: first checkout. Only ./trunk is needed. 4. General Update-commit Routine The 'update-modify-commit' routine should be one's daily work. However, there is going to be more topics as comments. 4.1. Updating to the newest revision; 4.2. Applying modifications and resolving conflicts (if any); 4.3. Commiting a new revision once done. 5. Lock Or Not? Although locking is a feature of svn as well, it's very easy to break or steal a lock, too. Based on the principle that our projects should be well divided into modules, merging is more encouraged than locking. 5.1. Using lock only when: 5.1.1. Editing some binary files (images, media files, doc files - if there's no external merging applications); 5.1.2. Of course, the time you think it's very, very, very necessary to make a lock. 5.2. When you've done that, make sure you: 5.2.1. Keep good COMMUNICATION with your colleagures; 5.2.2. Unlock those files AS SOON AS modifications are done. 5.3. At last, when breaking or stealing a lock, TALK to the one who applied locking (we are not a huge team, dude)! 6. Making Trunk Stable When working on a BETA or PRODUCTION project, always remember to make current trunk stable. There would be some strict rules to make it so, such as 'always creating branches when modification and make full test in branch' or 'making and sending patches to admin and only admin can modify trunk', but we'll make it more flexbible. 6.1. Updatng your project and resolving conflicts in time. Communicate with colleagues when necessary. 6.2. Perform proper test before commiting. 6.3. Before working on tasks that are involved with many files, or may affect a lot to the project, such as adding new features or performing some 'big' tests, create a branch. 6.4. Before coding, think about how to test your code first. 7. Adding Messages 7.1. Although svn can show difference between revisions, it is still strong recommended that writing what you've done when commiting changes. 7.2. Commit message should include 'what you've done to which file' seperately. 7.2.1. A sample log file may be used as template: /path/file1 change1 change2 ... /path/file2 change1 change2 ... /path/file3 added for what purpose ... (TBD) 7.3. If it is not involved with trunk stability, commit as few files once as possible. 8. General Code-test Routine 8.1. Project administrator should assign code-test tasks in time. 8.1.1. Tasks may include bug fixing, feature adding, testing, etc. 8.2. Project members keep performing the update-commit routine for bug fixing and feature adding. 8.3. When 8.2. is done, testing task will be assigned. After 8.3 is done, all related tasks can be closed then. 9. General Internal Branch-debug Routine 9.1. Internal tests will be performed when project administrator thinks it's time to do so. An internal test team will be founded then. 9.2. While others are working on the main trunk at the same time, internal test team will create a new branch, and test with proper test cases. 9.3. When test is done, a report should be sent back to project admin so that he can start assigning tasks of the code-test routine. 10. General QA Debug-release Routine 10.1. QA test will be performed when the whole project goes stable. 10.2. If an internal test branch is tested and proved to be stable, it should be tagged and will be sent to the QA team. 10.3. When test is done, a report should be sent back to software team so that he can start assigning tasks of the code-test routine. 10.4. General customer's debug-release routine works the same as this. Both QA's and customer's test should be treated as 'external', which are of the same importance (that is, they are both important to our team - hopefully). 11. Repository Backup 11.1. Daily local full backup is performed every night. Dump file will be stored locally, replacing the old dump file. 11.2. Daily remote incremental backup is performanced every night. Dump file will be transfered though ftp. 11.3. Monthly (or weekly) remote full backup is performed every weekend (or at the end of the month). Dump file will be transfered though ftp. 11.4. Monthly (or weekly) local full backup is performed every weekend (or at the end of the month). Dump file will be stored in DVD, and those DVDdiscs will be considered sensitive, and kept only by section manager. No additional copies is allowed. |