BTP300 Project Requirements 20113
BTP300 Fall 2011 | Weekly Schedule | Student List | Project Requirements | Teams and their Projects | Student Resources
Due Dates
Assignment 1 - Line Editing Facility | September 23 |
Assignment 2 - Field Classes | October 28 |
Assignment 3 - More Field Classes | November 18 |
Assignment 4 - Application | December 9 |
The official due dates are in Moodle. If there are any discrepancies, the due dates in Moodle shall apply.
Project Requirements
Each game is a team effort. The structure of each team is up to the team members. Each member must contribute their own work in a selected area or areas of their choosing.
Stage 1
- Line Editing Facility - Coded and Submitted Individually
Stage 2
- Field Classes - Coded and Submitted as a Group
Before continuing stage 2, please do the following
- Read Hints for Using SVN to collaborate on school projects
- Update your team's wiki page with your team's repository path information under Repo Path
- Add assignment 1 to your team's repository
- Checkout your team's empty repository to a new directory on a local computer
- Create the branches, tags, and trunk subdirectories
- Under branches create a subdirectory for each team member
- Under the team leader's branch create a new subdirectory named assignment_1
- Move up to the head of the repository directory and add this directory structure by right clicking on ...SVN/Add
- Commit the directory structure to the server by right clicking on SVN Commit. Add the comment "Created Directory Structure"
- Add assignment 1 to the branches sub-directory, compile it, and run it. If the assignment runs successfully add it and commit it to the repository
- Branch the committed assignment to trunk
- Your team members can now start their own work
- Create an Visual Studio Project named assignment_1 in trunk
Your team members should checkout your team's empty repository, add the branches, tags, and trunk directories and create the initial code [[]]
- Create a directory with your seneca id under the branch sub-directory of your team's repository. This will be your home directory for development. For details see
Directory Structure
|-- Team_Repository_Account +--branches | +-- member-id1 <-- this is a team member's home within branches | +-- Task1 | +-- Task2 | +-- member-id2 <-- this is a team member's home within branches | +-- Task1 | +-- Task2 | +-- Task3 | +-- member-id3 <-- this is a team member's home within branches | +-- Task1 +--tags | +-- R0.1 | +-- R0.11 | +-- R0.2 | +-- R0.21 | +-- ... | +-- R0.3 | +-- R0.31 | +-- ... | +-- R1.0 | +-- R1.1 +--trunk
branches
- branches is the common directory for all team members' workspaces.
- Each team member should create their own home directory or workspace (member-id1, member-id2,...) for their own development tasks within branches.
- Each team member should divide their workspace into several sub-directories (workspaces) during the development of the project. These workspaces(Task1, Task2, ...) are usually copies of the trunk to be worked on.
- These sub-directories(Task1, Task2,...) are called branches of trunk. When the word branch is used as a verb, it means copying the whole trunk into a sub-directory, either in branches or tags.
tags
- tags is the directory that holds copies of successful stages of trunk throughout development. (Also called as Milestones)
- tags are never modified or edited. You may branch a directory of tag into branches under a workspace and then modify the branch and apply the changes back to trunk, but you should never change the contents of a tag
- The action of branching the trunk into tags is often referred to as a release.
- We use the tags directory to submit the work for marking. Your instructor will specify the requirements of a release.
- A release is usually tagged by a version number like: R0.1, Prj0.2, As1_1.0
- When a release is due, your instructor will always mark the latest version of that release.
- If R0.3 is due, and R0.3, R0.31, R0.32 are present in tags, then your instructor will mark R0.32
trunk
- trunk is the directory that holds the project in its current stage, complied and run-able
- trunk should never hold non-compiled code. Usually trunk is an exact copy (or better than) the latest version in tags.
- Since only one project is within the repository, trunk has no project level sub-directory and is the root of the project.
Stage 3
- More Field Classes - Coded and Submitted as a Group
Stage 4
- Application - Coded and Submitted as a Group