2d8ef61e80
* rename docs to docs-pre-merge * add wiki content based on commit e4d4b10424f24eed6583ea0e998da8aa32a27a3f * replace wikilinks with markdown links in _sidebar * use sidebar link text as title via ` autoHeader: true` * rename files with `:` or `,` in the name * use the wiki Home page as entry point instead of the repo README
3.6 KiB
A concept that is especially confusing to newcomers that do not have a lot of Git experience is Terasology's multi-repository workspace. In the following, we try to shed some light on what "multi-repository workspace" means in the first place and how it affects your development workflow.
The Workspace Root
Your Terasology workspace is created by cloning our engine repository (see the first step in the Contributor Quick Start). The directory this creates will be considered your workspace and whenever you'll be in this directory, you'll be in your workspace root.
The workspace root content structure equals what you can see in the engine repository. You'll find the same directories and root-level files in your workspace root that you will also find in the engine repository.
The modules sub-directory
Directly after cloning the engine repository, you could enter the modules sub-directory and notice that it does not have any sub-directories itself. However, after following the Contributor Quick Start further, you'll eventually notice that new directories pop up in your modules subdirectory. These directories are the local representation of modules. Whenever you build and start Terasology from source, the modules you can see listed in the Advanced Game Setup are the once locally available in your modules sub-directory.
These module directories typically show up as soon as you run either of the following commands:
groovyw module init <distro>, e.g.groovyw module init iotagroovyw module recurse <module>, e.g.groovyw module recurse JoshariasSurvivalgroovyw module get <module>, e.g.groovyw module get Health
What these groovyw module commands do in the background is clone a single (in case of get) or multiple (in case of init and recurse) module repositories into your modules sub-directory. Each directory this creates in your modules sub-directory will contain the exact contents the respective module repository in the "Terasology" GitHub organization does.
The same is true for the libraries sub-directory, only with library repositories like gestalt or TeraNui residing in the MovingBlocks GitHub organization instead. However, in your basic Terasology contributions, you'll rarely have to care about this.
What this means for your development workflow
Whenever you are in your workspace root or any of its sub-directories and execute git commands (e.g. git switch, git commit, git push), these commands will target the upstream engine repository which usually is either the original Terasology engine repository or your fork of it. This is true for all sub-directories except the sub-directories of modules and libraries.
Whenever you are in a sub-directory of modules and libraries, the git commands you execute will target the respective upstream module or library repository. For instance, when you're in the modules/Health sub-directory, your git commands will either target the original Health repository or your fork of it.
