Version control for Smalltalk / Seaside?

Question

I'm primarily a Java EE developer. I've been asked to explore the possibility of using Smalltalk / Seaside in an upcoming web project. As you can imagine, this has led to many interesting questions.

How does a team of developers implement software versioning and revision control with Smalltalk / Seaside. Can you use Subversion or Git?

From what I understand, Smalltalk uses an image rather than saving each class to it's own file. How does that affect the ability to manage source code revisions, particularly across a team?

Many thanks for any insight you can provide!

Answer 1

Setup for Pharo (and Gemstone)

Each developer works in his own image. Every change to a method he makes is saved locally in the changes file. This allows recovering when crashing the image. Commits are made by creating a monticello file, having a package name, sequence number and the name of the developer. It knows its ancestry. This file is saved to a WebDAV server. Here it is picked up by a Jenkins task. This runs the unit and integration tests and creates new images, so developers can start with a fresh image (at least) every day. Here are some details on merging using monticello. The product composition (package structure) is another monticello file containing a metacello description. This also allows one to develop on Pharo and deploy on Gemstone. Once in a while you need to add class migrations.

For non-smalltalk dependencies and development, test acceptance and production differences, add the creation of virtualbox images using vagrant, chef-solo (or puppet, hopefully soon Coral), veewee. They are of course version managed using git.

In addition to using static code-quality control tools (smallLint, also checks differences between smalltalk dialects), add Moose and create your own context dependent, dynamic visualizations of the project (humane assessment)

In VisualWorks Smalltalk the local developer uses STORE with a relational database (e.g. PostgreSQL) to store local commits. The code is organized in bundles of packages, with namespaces. A replication script is used to copy the local versions to and from a central database. From there the flow is the same as with the Pharo setup.

[update] At Esug2012, Dale Henrichs presented work to make it possible to use git and github to manage smalltalk code for multiple dialects. Basically, a file structure was defined (Cypress for Amber, Gemstone, Pharo, Squeak, VisualAge, STIG for VisualWorks) to store smalltalk methods in directories. This is currently aimed more at the exchange of code between dialects than as a replacement for the native SCM.