CVS Repository Setup Dialog

Help index

Introduction

Single repository setup

In a single repository setup, all of the sources of the system are contained in one big repository - this includes the sources of the base system classes, as well as the sources of any application.
Notice, that with the exception of eXept itself and a number of customers with special contract, this is normally not a realistic setup for most other users (in fact, even within eXept, multiple cvs servers are used for individual projects).

In a single repository setup, all that needs to be configured, is the CVSROOT of a repository, which contains source containers for all projects. As an example, the following setting will acomplish this:

(Notice, that the above picture also demonstrates a setup with a changed cvs-binary directory)

In this concrete example, all source-requests for all projects (i.e. not only the stx-projects) will be tried to be resolved from the repository located on the "cvs.smallalk-x.de"-host.

Multiple repository setup

In a multiple repository setup, various cvs repositories are responsible for resolving source requests. The repository is choosen by the module component of the packageID (i.e. the first component up to the separating colon).

For almost all situations, this is the recommend setup, and the most useful setting would be:

  1. Use a repository on one of you own hosts as the default CVSROOT. For performance reasons, this may even be a local cvs installation on you development machine, or at least a machine within your local network.

  2. Use the eXept repository (":pserver:cvs@cvs.smalltalk-x.de:/cvs/stx") for all projects under the "stx" module. I.e. in the settings dialog, add a per-module entry for "stx" as follows:

  3. If not already enabled, do enable the repository caching mechanism. If enabled, checked out source files are cached on the local machine to speed up future accesses.
    Please do expect some initial delays, when source files are fetched for the very first time (this will lead to short delays in the browser, whenever it needs access to a sourcefile, which has not been previously fetched).
    These delays will vanish as soon as enough source files have been cached.

Setting up a CVS Repository

Please refer to your CVS-Installation's user manual, online help or command usage documentation on how to initially setup and maintain a cvs resository.

Attaching to another Repository

Additional data security is optained, by using a master repository, which is periodically copied to a slave repository, which is given to third party users. For example, in the eXept setup, the repository at ":pserver:cvs@cvs.smalltalk-x.de:/cvs/stx" is actually only a passive copy of a fraction of the real repository - sensitive parts and customer projects are not visible in that slave repository.

CVS Settings Dialog

Repository Enabled

If disabled, source requests will be tried to be resolved from the local file system (by searching for a directory structure corresponding to a packageID-path).

CVS Binary Executable Path

Optionally specifies the path to the "cvs" (or "cvs.exe") command.
This is only required if you do not have cvs installed along the default PATH, or if you want to use your own private version of the cvs command.

CVSRoot Default

Specifies the CVSROOT (see cvs documentation) for all classes which do not belong to a cvs-module listed in the CVSRoot-per-module list.
I.e. its the fallback CVSRoot used for all other classes, not listed below.

CVSRoot per Module

In ST/X, class packages form a hierarchical tree and are mapped in the cvs repository to source file containes located in subdirectories below a so called module root. The module itslef is specified by the first component of a package path. For example:
The "Array"-class is found in the "stx:libbasic" package.
Therefore, its module is "stx" and its cvs container is found in the "libbasic" sub-directory, of the CVS-repository which has been associated to the "stx" module.

Placing your own packages into a separate module (typically, you would use your company name as module-name) and specifying a separate CVSRoot for this module, allows you to manage your own classes in a separate source code repository.
Of course, this also allows for multiple independent repositories to be defined and maintained in bigger organizations.

You can attach to the stx-repository (readOnly) by specifying the following CVSRoot for the "stx" module: :pserver:stx@www.exept.de:/stx A CVS-login is required when accessing this repository for the very first time. Perform this login either via the cvslogin command-line utility, or by pressing the login-button in the settings dialog. The pasword for the stx repository is "stx".

Source Cache

Performing a slow CVS-checkOut operation for every class which is visited in the browser does slow down the system's responses - especially the search functions (senders/string-search etc.) may become unusably slow.
To avoid this, the sourcecode-manager keeps track of already checked-out classes and remembers those in a cacheDirectory. This cache may grow over time, as it remembers multiple versions of all classes of which source code has ever been asked for.
The default location for this cache is "/tmp/stx_sourceCache" (unix) or "\local files\Temp\stx_sourceCache" (windows).
Over time, this directory may grow and should be purged from time to time (The purge operation removes old versions in the cache and leaves the youngest only).
It is not dangerous, to remove those old files, as they will be re-checked out as required (for example, when you do a "compare with previous" operation later).

Use Local Files (First)

If enabled, source requests will be first tried to be resolved from the local file system (by searching for a directory structure corresponding to a packageID-path), then via a CVS request.
This is a useful setup, if your CVS connection is very slow or unreliable, as most of the CVS requests are avoided. However, it has the severe drawback, that you may never modify any of the local source files.
Be aware, that the source code manager trusts the versionNumber found in the sourcefile, to correspond to the versionNumber of the compiled class. Manually editing a sourceFile, will certainly lead to invalid sourcecode being shown in the browser.
The reason is that in order for the browser to be able to fetch a methods source, it fetches the source (by release) and extracts a methods source from the file position as kept in the method-object.
If the file is modified, this file position information becomes invalid.

Keep this in mind, when enabling this feature.

Check for halt and other bad message sends

If enabled, code which is about to be checked into the repository is checked for a number of "considered bad" code constructs. Among them are:


Copyright © eXept Software AG, all rights reserved


Doc $Revision: 1.3 $ $Date: 2006/08/25 09:22:04 $