All code should be maintained in version control. Currently we are using GitLab for this.

This documentation describes the intended layout of the version control repository. There are still a few areas not yet brought into this scheme.

The repository is located at ist-git@git.uwaterloo.ca:cscf/odyssey.git. The current production branch is prod. Changes committed should have an RT id somewhere in the commit message in the form of (RT#{id}) since we have a webhook which then leaves a link to the commit in the corresponding RT ticket.

For each significant system update, we create a git branch, which is in the form of (RT#{id}-{description-name}), with the description name being lowercase and separated by dashes.

The git command used is

$ git worktree add -b RT1234567-description-name ../RT1234567

which generates a linked working tree associated with the repository.

It also creates a new working directory parallel to the current repository, which contains the branch file and can be used for simultaneous work on that branch. After changes are complete, the branch can be checked out simultaneously alongside any other branches in other directories if desired.

Within the project are the following directories:

  • java — Java code hierarchy. Java code resides in sub-packages of ca.uwaterloo.odyssey in accordance with the standard Java package naming conventions. See Java coding standards for more information.
  • project — Individual project directories. Within this directory there is a directory for each project. The project directory contains all project files, except for Java and Python code. Each project’s directory should contain a python symlink to the project’s Python code.
  • python — Python code hierarchy. Python code resides in sub-packages of uw. See Python coding standards for more information.
  • static — Static files hierarchy. This directory contains static files for the front-end of each project in the appropriate subdirectories.
  • sql — SQL code hierarchy. Within this directory are SQL scripts to be used by the projects.
  • vagrant — Vagrant setup hierarchy. A mixture of configuration files and scripts needed to setup a Vagrant guest machine can be found here. See Vagrant documentation for more information.

Additionally, there are a few legacy directories which should be gradually cleaned up.