Open main menu

CDOT Wiki β

BTP300 Project Requirements 20113

Revision as of 22:32, 4 October 2011 by Chris Szalwinski (talk | contribs) (Project Requirements)

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

Stage 2

Before continuing stage 2, please do the following

  1. Read Hints for Using SVN to collaborate on school projects
  2. Update your team's wiki page with your team's repository path information under Repo Path
  3. Add assignment 1 to your team's repository
    1. Checkout your team's empty repository to a new directory on a local computer
    2. Create the branches, tags, and trunk subdirectories
    3. Under branches create a subdirectory for each team member
    4. Under the team leader's branch create a new subdirectory named assignment_1
    5. Move up to the head of the repository directory and add this directory structure by right clicking on ...SVN/Add
    6. Commit the directory structure to the server by right clicking on SVN Commit. Add the comment "Created Directory Structure"
    7. 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
    8. Branch the committed assignment to trunk
    9. Your team members can now start their own work


    1. 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 [[]]

  1. 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


Stage 4