Outpost Universe Repositories

The Outpost Universe community maintains source code and other development documents within two different repositories. One is an online hosted Subversion (SVN) repository and the other is a Git repository hosted on GitHub under Outpost Universe. Both repositories are still under active use.

Index

• Git Repository Specifics
• Transferring SVN to Git Repositories

Outpost Universe on GitHub is the newer repository and is becomming the primary repository for projects that do not directly contain the game download. Ongoing work is occurring to migrate appropriate projects from the SVN repository to the GitHub repository. You can find the GitHub site at https://github.com/OutpostUniverse.

To access and manipulate the GitHub repository, most community members either use the graphical tool TortoiseGit or via Git on the command line. Tortoise Git may be found at https://tortoisegit.org/.

Outpost 2's SVN repository was hosted online through VisualSVN Server. The repository is no longer maintained and users are encouraged to use GitHub for source code control instead. See above for Outpost Universe's official GitHub site.

When a programmer is first introduced to using a repository, it can feel like a burden to integrate into their workflow. However, the benefits of revision control in a project that spans years and has several people manipulating it are well worth the growing pains. For specific guidance on syntax and use of either SVN or Git, see their respective pages. Below are general guidelines that apply to any version control system. These are meant as guidelines only and sometimes may need to be ignored in certain situations.

Version Control Best Practices

• Daily, before editing the source code, attempt to pull changes from the online repository to check if others have committed in your absence.
• ALWAYS COMPILE AND RUN your code before committing changes. This way you do not accidently submit changes that break the application/library.
• If you need to commit code for a feature that is not yet working for any reason, open a new branch on the project for the code. This way when others review the code, the master branch still compiles and runs properly.
• When committing code, attempt to separate each new feature into a separate commit.
• Spend time writing quality commit messages that discuss why the changes were made. (https://web.archive.org/web/20210326041439/https://chris.beams.io/posts/git-commit/)
  • Include a subject line in the commit
  • Capitalize the subject line
  • Limit the subject line to 50 characters
  • Do not end the subject line with a period

    • Use the imperative mood in the subject line (not past tense)
    • If useful, include a body with the message. Explain what and why instead of how in the body
    • Separate subject from body with a blank line
• When finalizing a release of an application or library, consider tagging it with release number. This allows others to easily locate the exact source code associated with the release.
  • Consider using Semantic Versioning when determining release number. (http://semver.org/)
• Mark files and folders that should not be included in the actual repository in the ignore list.

- Go Back to Outpost 2 Mapmaking
- Go Back to Wiki Home Page