1
edit
Changes
Created page with '== Practical Guidelines == *READ the SVB book at red-bean.com. (FYI - Resources on the course wiki page.) **Understand the concept of source code version control. **Identify the …'
== Practical Guidelines ==
*READ the SVB book at red-bean.com. (FYI - Resources on the course wiki page.)
**Understand the concept of source code version control.
**Identify the basic operations you need to work with an SVN code repository.
*View these (or other) video clips:
**Best Practices for Subversion (SVN) [http://www.youtube.com/watch?v=MfLLDg7zWQg&feature=related]
**Subversion Basics with TortoiseSVN Tutorial [http://www.youtube.com/watch?v=fPUdXvjY_G4&feature=related]
** Subversion Branch Merge Tutorial [http://www.youtube.com/watch?v=4WC44T89VrY&feature=relmfu]
*Download and install TortioseSVN. Read the documentation whenever needed.(FYI - Resources on the course wiki page.)
*Set up the following directory structure for your SVN code repository
<pre>
/trunk
/branches
/tags
</pre>
Create a README file in the trunk. It should contain information about the project such as the names of the team members, the starting date of the project, a brief description of the project, command lines (or tools) to compile the source code, a script file to build the source code, and so son. Create a README file in a branch. It should contain the name of the person who's responsible for developing the class(or classes) in this branch. It should also contain '''a list of bugs fixed''' (including the names of the team members).
Create concise but informative change log files whenever you do commits. (To find out more about changelogs, do a Google search on Change Log Example.) Here are some links to get your started.
* ChangeLog (Wikipedia) [http://en.wikipedia.org/wiki/Changelog]
* examples [http://dddsample.sourceforge.net/changelog.html] [http://drupal.org/files/issues/changelog_7.patch][http://www.moleculargeek.net/pluglink/page-2.html]
* styles of coding [(http://www.gnu.org/software/guile/changelogs/guile-changelogs_3.html] [http://www.gnu.org/prep/standards/html_node/Change-Log-Concepts.html#Change-Log-Concepts]
'''Tags''' are meant to be snapshots of the trunk. Do not make any changes to a tag. You should tag when you are ready to make a release. For Release 0.2, store the three executables in a sub-directory of the trunk of your repository. Branch the sub-directory to A2.R0.2 under the tags directory of your repository. Do the same thing for Release 0.3.
== Collaboration Requirements ==
*Effective team work should produce '''high-quality code''' base. Team work is not an excuse for being lazy.
*Select a team leader who is responsile for merging branches with trunk.
*Divide the work of A1 Release 0.2 among the team members. Each team member should be responsible for developing one specific C++ class (e.g. CButton).
*Each team member should create a branch to work on that class.
*A branch should be labelled by the name of a team member (e.g. john).
*Everyone on the team can '''debug''' the source code in any of the branches. (Warning: The number of bugs fixed for a particular class reflect the '''quality''' of code initially developed (contributed) by the team member. This could affect the final marks that a team member could receive. In brief, each team member should '''work as hard as other team members'''. Do not contribute '''poor quality''' code to the code repository (i.e thh shared code base). A group evaluation scheme will be used to asses the performance of each team member.)
*READ the SVB book at red-bean.com. (FYI - Resources on the course wiki page.)
**Understand the concept of source code version control.
**Identify the basic operations you need to work with an SVN code repository.
*View these (or other) video clips:
**Best Practices for Subversion (SVN) [http://www.youtube.com/watch?v=MfLLDg7zWQg&feature=related]
**Subversion Basics with TortoiseSVN Tutorial [http://www.youtube.com/watch?v=fPUdXvjY_G4&feature=related]
** Subversion Branch Merge Tutorial [http://www.youtube.com/watch?v=4WC44T89VrY&feature=relmfu]
*Download and install TortioseSVN. Read the documentation whenever needed.(FYI - Resources on the course wiki page.)
*Set up the following directory structure for your SVN code repository
<pre>
/trunk
/branches
/tags
</pre>
Create a README file in the trunk. It should contain information about the project such as the names of the team members, the starting date of the project, a brief description of the project, command lines (or tools) to compile the source code, a script file to build the source code, and so son. Create a README file in a branch. It should contain the name of the person who's responsible for developing the class(or classes) in this branch. It should also contain '''a list of bugs fixed''' (including the names of the team members).
Create concise but informative change log files whenever you do commits. (To find out more about changelogs, do a Google search on Change Log Example.) Here are some links to get your started.
* ChangeLog (Wikipedia) [http://en.wikipedia.org/wiki/Changelog]
* examples [http://dddsample.sourceforge.net/changelog.html] [http://drupal.org/files/issues/changelog_7.patch][http://www.moleculargeek.net/pluglink/page-2.html]
* styles of coding [(http://www.gnu.org/software/guile/changelogs/guile-changelogs_3.html] [http://www.gnu.org/prep/standards/html_node/Change-Log-Concepts.html#Change-Log-Concepts]
'''Tags''' are meant to be snapshots of the trunk. Do not make any changes to a tag. You should tag when you are ready to make a release. For Release 0.2, store the three executables in a sub-directory of the trunk of your repository. Branch the sub-directory to A2.R0.2 under the tags directory of your repository. Do the same thing for Release 0.3.
== Collaboration Requirements ==
*Effective team work should produce '''high-quality code''' base. Team work is not an excuse for being lazy.
*Select a team leader who is responsile for merging branches with trunk.
*Divide the work of A1 Release 0.2 among the team members. Each team member should be responsible for developing one specific C++ class (e.g. CButton).
*Each team member should create a branch to work on that class.
*A branch should be labelled by the name of a team member (e.g. john).
*Everyone on the team can '''debug''' the source code in any of the branches. (Warning: The number of bugs fixed for a particular class reflect the '''quality''' of code initially developed (contributed) by the team member. This could affect the final marks that a team member could receive. In brief, each team member should '''work as hard as other team members'''. Do not contribute '''poor quality''' code to the code repository (i.e thh shared code base). A group evaluation scheme will be used to asses the performance of each team member.)
