Source Code Repository Setup Dialog
Source code repositories provide support for versioning of classes and packages (= projects).
The basic operations are "checkin" to save the state of a class, group of classes, or package,
and "checkout" to load a previous version's state. Also, various support functions are
provided, such as logging (who changed what) and diffing (comparing against an older version).
A number of different source code repository mechanisms are supported:
- CVS - a file/container based respository. This can be used both locally or
in a team via remote access to a central server host.
- SVN (Subversion) - a file/container based respository, similar to CVS, but newer.
- P4 (Perforce) - a commercial product which also supports team operation via a central server host.
- File-Repository - a simple respository which uses the local filesystem for versioning.
Only useful as a demo and for small classroom projects.
- DB-Repository - a simple respository which uses a relational database for versioning.
Only useful as a demo and for small to medium sized classroom projects.
- Mercurial - another free sourcecode management framework. Also the underlying mechanism used for Kiln repositories.
This is being developed, support for this repository type is experimental.
- Monticello - an archive-format for versioning and project interchange used by the Squeak
Smalltalk community.
Support for this repository type is experimental.
- STORE - a source code repository based on a central relational database which is accessed via ODBC).
This is a vendor specific repository from Cincom for their Visualworks Smalltalk product.
Support for this repository type is experimental.
Each type of repository is handled by a separate source code manager. For example, the CVS support
is realized by the CVSSourceCodeManager.
Smalltalk/X organizes classes in modules and packages and associates a so-called packageID to every class and method.
The packageID consists of the concatenation of the module and package.
For example the packageID "stx:libbasic" refers to the "libbasic" package in the "stx" module.
Or, "exept:expecco/plugins/manualTest" refers to the "expecco/plugins/manualTest" package in the "exept" module.
In a single repository type setup, all modules are managed by the same type of source code manager.
For example, if you use CVS to manage your own local sources,
and want to access the public exept repository (which is a CVS repository).
In this mode of operation, all you need is to set the "Default Repository Type" to CVS
and configure the individual CVSRoots in the CVS-settings dialog,
so that the "stx"-module is accessed from the exept public repository,
and your own classes from your private (local) repository.
Use this, if you have a local non-CVS repository (P4, SVN or HG) and you still want to access
the public exept CVS repository.
In this case, choose your own repository type as "Default Repository Type",
and define "Type = CVS" for the "stx"-module in the "Per Package Setting".
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).
Specifies the default type of source code manager (CVS, SVN, P4 etc.) to be
used for all packages which are not listed in the per-package settings list.
I.e. its the fallback type used for all other packages, not listed below.
Each package (= project) can be managed by a separate source code manager on possibly different hosts.
This list defines the type of source code manager (CVS, SVN, P4 etc.) on a per-package basis.
The package is given as a match-string, thus associating "goodies:foo/*" to the P4 manager,
will configure all packages below the "goodies:foo" package to be managed by a perforce
source code manager. Further details (location of the P4 reporitory) are then to be specified
in the corresponding manager's configuration tab (in this case: the P4 configuration settings).
Performing a slow 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 can keep track of already checked-out classes
and remembers those in a cache directory. 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 "<userDefault>\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).
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.
If enabled, any method's source code is remembered as string in the image,
once it has been aquired either from a file or from the repository.
As a result, your image will grow by roughly 10-20Mb over time.
However, source code access and search operations in the browser will become much faster
over time (until the working set of source code has been loaded).
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:
- Leftover sends of the
#halt
-message
- Sends of the
#error
-message (i.e. without descriptive text-argument)
If enabled, feedback information about what is going on will be sent to the Transcript window.
Copyright © eXept Software AG, all rights reserved
Doc $Revision: 1.5 $ $Date: 2012/03/03 09:45:01 $