When working on a specific model in Theon other models are used in the background by the toolkit, specifically the self model (representing the SchemaTree working copy database, XSDDB). These have their own model library directories which are built as necessary in the ModelLibraryHome. By default the toolkit uses ~/.theon/model/library for this purpose. The content of this directory can always be discarded as it should be able to be re-created by the toolkit from the Theon installation itself. Often directories are created in here simply for transient transform derivations. There is not normally any need to directly refer to the content here. The default directory can be changed by setting the THEON_MODEL_LIBRARY_HOME environment variable appropriately.

When giving a specific model argument to the toolkit then the appropriate ModelLibrary is looked for in a search path. By default this just includes the installation directory (which is /usr/share/theon/model/library by default). The search path can be changed by setting the THEON_MODEL_LIBRARY_PATH environment variable to a colon separated list of directory paths. In addition to the search path the toolkit also looks in the current working directory (or a directory specified in an optional arugment). Note that a directory matching the model library name given is searched for at each path - this is often the same as the name of the model contained in that directory but need not be.

Associated with a ModelLibrary are one or more LiveProfile files. Each defines the particular PostgreSQL connection parameters that are used for the toolkit to work with that realised instance of the model. These files are all held under a directory named the same as the model name (MODEL, note not necessarily the same as the ModelLibrary directory name - MODLIBDIR). These directories are held in the LiveProfileHome. By default the toolkit uses ~/.theon/model/profile for this purpose. There is not normally any need to directly refer to the content here. The default directory can be changed by setting the THEON_MODEL_PROFILE_HOME environment variable appropriately.

Live profiles are so called as they are not preserved with the corresponding ModelLibrary. They represent a current (potentially transient) instantiation of the model as a physical PostgreSQL database. They may refer to a local or remote database which may be the live production service database or a development snapshot. Some live profiles are created automatically by the toolkit to manage background connections to models, specifically the connection to the instantiation of the self model as the XSDDB.

A ModelLibrary is created (and configuration can be altered) by a specific toolkit command. This creates the directory MODLIBDIR if necessary (when its not just the current working directory) and the MODEL.mol configuration file. At the same time a LiveProfile for the model will be created. By default this will connect to a database named the same as MODLIBDIR on the localhost, but optional arguments can be used to setup different connection parameters. The same toolkit command can be used to change the LiveProfile or add additional LiveProfile+s. A +ModelLibrary can also be created that is a shadow copy of another. In this case the search path is altered to include the original ModelLibrary so that not all content needs to be replicated.

Theon does not itself do any version control, although the toolkit does have support for Git for local (or remote) version control and release management. By default the ModelLibrary is held in a local filesystem (under the current working directory unless otherwise specified). However, in almost all practical scenarios, except perhaps initial testing, the ModelLibrary would ideally be held in a version control system (of any type, Git or Subversion for example). To achieve this in practice, simply ensure that the current working directory (or ModelLibrary directory) is a working copy within a repository under version control. The commit and merge of added, modified or removed files within the ModelLibrary is achieved manually using the standard tools for the version control system in use. If Theon is being used in a private installation, then the version control system master is likely to be on the same host. If Theon is being used to manage a central database in a production service, then there may be many developers and a centrally hosted repository instead. As stated, Theon is agnostic; it just maintains the ModelLibrary in a directory in a filesystem, irrespective of whether that filesystem is actually on a local disk or a networked disk (private or shared), or the directory is a working copy of a checked out repository from a version control system.

Developers who want to make changes to public models - and have them included in future official releases of those models - will need write access to the repository in order to actually commit their changes. Alternatively, developers at another site who want to fork development of the model can take a snapshot from the repository and re-instate this into a repository under their control. ALternatively a repository can be cloned from a packaged ModelLibrary and worked on entirely independently.