Sourcecode & Revision Management (General)

Introduction
Choosing a Sourcecode Management Scheme
Setting up the Sourcecode Management

Introduction

ST/X includes interface classes and browser support which allow Smalltalk classes to be managed by file or database based sourcecode revision management systems, such as CVS, SVN (subversion) or P4 (perforce).

Also, mixed configurations are possible, in which different class packages are located in different repositories. This is especially useful when accessing exept's ST/X master repository (which is a CVS repository), while at the same time, local package sources are to be stored in another (local) repository.

Choosing a Sourcecode Management Scheme

Currently, the source code management (SCM) scheme which is best integrated into ST/X is CVS. All files for the whole build and deployment process can be generated and checked into CVS from within the ST/X system browser. This allows for completely unattented builds to be done automatically, by systems similar to jenkins (hudson), or batch/shell scripts.

However, the choice of which SCM scheme to use may also depend on the existing infrastructure. If your company uses SVN or Perforce to package and build products, this may be a good choice for ST/X projects as well.

The following table lists the currently supported SCM schemes and their pros and cons:

Name Description Pro & Con

CVS Concurrent
Source Code Management System +local and remote operation
+best integration
+supports file based command line operation
+fully automated build

-slow if remote and slow connection
-class renaming troublesome
-class moving troublesome
-no branch support (*)
-requires central server

SVN Subversion
Source Code Manager +local and remote operation
+good integration
+supports file based command line operation
+almost fully automated build

-requires central server

P4 Perforce P4
Source Code Manager +local and remote operation
+supports file based command line operation

-commercial; requires license

Git Git Source Code Manager +local and remote operation
+supports file based command line operation
+good support for offline changes

-unfinished; highly experimental (*)

Mercurial Mercurial (hg)
Source Code Manager +local and remote operation
+supports file based command line operation
+good support for offline changes

-unfinished; highly experimental (*)

Monticello Monticello Packaging System
Squeak Source Repository +local and remote operation
+standard in Smalltalk
+support in Squeak, VW and V'Age
+good support for offline changes

-only for code interchange
-no file based command line operation
-no build support
-unfinished; highly experimental (*)

STORE STORE DB
Cincom/VisualWorks Source Reporitory +local and remote operation
+standard in VW

-only for code interchange
-no file based command line operation
-no build support
-new database format is not supported (*)

Filebased Dummy SCM
using the Local Filesystem +fast
+standalone: no installation required

-only for small "one-man" projects
-only local operation
-no branch support (*)
-limited build support

DBbased Dummy SCM
using a Local Database +fast
+standalone: no installation required (uses SQlite)
+remote: uses ODBC to access server

-only for small projects
-only local operation
-no branch support (*)
-limited build support

(*): some cons are not resulting from limitations of the SCM scheme itself, but the interface implemented by ST/X classes.

Name	Description	Pro & Con
CVS	Concurrent Source Code Management System	+local and remote operation +best integration +supports file based command line operation +fully automated build -slow if remote and slow connection -class renaming troublesome -class moving troublesome -no branch support (*) -requires central server
SVN	Subversion Source Code Manager	+local and remote operation +good integration +supports file based command line operation +almost fully automated build -requires central server
P4	Perforce P4 Source Code Manager	+local and remote operation +supports file based command line operation -commercial; requires license
Git	Git Source Code Manager	+local and remote operation +supports file based command line operation +good support for offline changes -unfinished; highly experimental (*)
Mercurial	Mercurial (hg) Source Code Manager	+local and remote operation +supports file based command line operation +good support for offline changes -unfinished; highly experimental (*)
Monticello	Monticello Packaging System Squeak Source Repository	+local and remote operation +standard in Smalltalk +support in Squeak, VW and V'Age +good support for offline changes -only for code interchange -no file based command line operation -no build support -unfinished; highly experimental (*)
STORE	STORE DB Cincom/VisualWorks Source Reporitory	+local and remote operation +standard in VW -only for code interchange -no file based command line operation -no build support -new database format is not supported (*)
Filebased	Dummy SCM using the Local Filesystem	+fast +standalone: no installation required -only for small "one-man" projects -only local operation -no branch support (*) -limited build support
DBbased	Dummy SCM using a Local Database	+fast +standalone: no installation required (uses SQlite) +remote: uses ODBC to access server -only for small projects -only local operation -no branch support (*) -limited build support

CVS

CVS is a file based source code revisioning system. This is the main scheme used by exept itself for the ST/X repository. It is best integrated into both the browser and the automated build process (the reason is simply due to the fact that CVS has been around for a long time, and we have spent a lot of time integrating it into ST/X. Not because we think that CVS is the best SCM around, which it is definitely not!). Classes and packages can be checked in/out from the browser, compared against older versions, and checked out as a whole tree (including make and build files) for automatic builds. On the command line, builds only require a "cvs checkout" followed by "make". Therefore, integration into automated build servers (such as jenkins) is trivial. More info in CVS Sourcecode Manager and CVS Introduction.

SVN (Subversion)

SVN is a file based source code revisioning system. ST/X support for this scheme was developed and mainly used by students of the University of Prague to manage and build their projects. It is well integrated into both the browser's and their automated build process. Classes and packages can be checked in/out from the browser, compared against older versions, and checked out as a whole tree (including make and build files) for automatic builds. Builds only require an "svn checkout" followed by "make". Integration into automated build servers (such as jenkins) is trivial. More info in SVN Sourcecode Manager (to be written).

Perforce P4

P4 is a file based source code revisioning system. ST/X support for this scheme was developed, maintained and used by one of our major ST/X customers. The P4 interface is avaliable royalty free. However, P4 itself is a commercial product which must be licensed separately. It is integrated into the browser's and their automated build process. Classes and packages can be checked in/out from the browser, compared against older versions, and checked out as a whole tree (including make and build files) for automatic builds. Builds only require a "perforce checkout" followed by "make". More info in P4 Sourcecode Manager (to be written).

Git

Git is a file based source code revisioning system which supports multiple repositories and convenient merge operations to resynchronize after offline work. Support for Git is currently in an early experimental development phase. More info in Git Sourcecode Manager (to be written).

Mercurial (hg, kiln)

Mercurial (hg) is a file based source code revisioning system which supports multiple repositories and convenient merge operations to resynchronize after offline work. Support for Mercurial is currently in an advanced development phase, and eXept plans to migrate from CVS to Mercurial. However, there are still some rough edges, which require actions on the command line. Currently, Mercurial is used for some subprojects and the experience flows back into the UI improvement process. More info in Mercurial Sourcecode Manager (to be written).

Monticello

Monticello is the main scheme used in the Squeak Smalltalk community to package, deploy and distribute source code. Monticello packages are technically zip archives which wrap a package's source together with a binary dump of the package plus some meta information. The ST/X monticello adaption can only be used for code interchange - ST/X can both read and write monticello packages (including the binary dump). Packages generated by ST/X may optionally include build support files (for stc-compilation), which are ignored when loaded into a non ST/X system. However, it does not support any automated build process - you have to manually unwrap the package files into the appropriate target directory and execute make (bmake / mingwmake) there from a command line shell.

STORE Database

STORE is the main scheme used in the VisualWorks Smalltalk community to package, deploy and distribute source code. STORE uses centralized databases, which are accessed via ODBC, MySQL or Postgres. The ST/X STORE adaption can only be used for code import. Neither export, nor any build support is provided.

Due to the fact that Cincom has recently changed the DB-scheme, the current version of the STORE manager may fail to access a remote STORE database.

The STORE source code manager is an unsupported, experimental goody. It may require extra work to make it fullfill your particular needs - especially an adaption to the new database scheme needs to be done.

File- and DB-Based Dummy SCMs

These two managers are provided as toy/demonstration frameworks. They can be used for versioning of small, local one-man projects only. They may be useful for simple versioning if no CVS or SVN installation is possible or wanted. They can also be used as a guide to how interfaces to other SCM schemes are implemented.

Finally, they can be used temporarily, when working offline and the main repository (such as CVS) is not accessible.

Setting up the Sourcecode Management

Use the laucher's "Source Code Management" setup dialog to define the source code management scheme on a per-module base. Every class is assigned to a package identifier, which actually consists of a path name into a repository directory (similar to a URL). The first specifies both the top-level directory AND the SCM-scheme to be used.

Therefore, a packageID like "stx:goodies/webServer" specifies that the file's path is "stx/goodies/webServer" inside the "stx" module.

ST/X uses a mapping scheme, in which different repositories can be assigned to different modules. In the settings dialog, you can define on a per-module basis, which source code scheme should be used.

As a first try, specify that the Filebased or DB-(database) manager should be used for the "demo" module. Then, create a class and change its package to "demo:myFirstDemoProject".

Notice, that the browser will offer additional menu items in its source-code-management menus. -- more to be written --

<cg at exept.de>

Doc $Revision: 1.48 $ $Date: 2021/03/13 18:24:51 $

Sourcecode & Revision Management (General)

Contents