Version control for Smalltalk / Seaside? [closed]

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!

Osterhus

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.

Ameline

Answer 2

Short answer: you cannot (for now) use Git or Subversion.

Even shorter answer: you don't need it :)

Large answer: See Stephan explanation on how Pharo it self is created :)) Of course, if you are used to file based systems, this will be strange at first instance, but once you start working, you will realize that you have all the tools you need to version control (monticello –this is the replacement for Git/Subversion), and for creating complex installations (metacello –this is the replacement for things like maven). With some work (as always and with any platform you choose), you can setup your own continuous integration server (jenkins or hudson or whatever) and soon you will be team working just as in other environments, but with one big plus: you will be developing Seaside/Smalltalk :P

EDIT: This is very old answer and a lot of time passed. Since then Pharo has evolved and this is no longer true, since you have a good integration with Git (Named iceberg) that provides everything needed, and most of the pharo based projects are now on it (and pharo itself, see https://github.com/pharo-project/pharo)

Witwatersrand

Answer 3

There are some tools for Svn/Git, but IMHO it is much better to go with the flow here and use Monticello because Monticello gives you a very similar experience as git does, but much simpler to use and much more integrated with the "Smalltalk way".

You did not specify which Smalltalk, but if you are going to use Pharo it is definitely Monticello (and when stuff gets complicated - Metacello on top) to use.

Halfmast

Answer 4

Smalltalk has its own packaging / versioning systems, where the source code packages are under control, splitted, merged, etc. Which Smalltalk dialects do you plan to use? Pharo has Monticello and Metacello, Squeak has Monticello, VisualWorks has STORE.

Conquer

Answer 5

Development in Smalltalk is usually more productive - but you have to learn about new tools first: Monticello/Metacello for packaging (think of it as saving a package in an own ZIP file with mcz extension and an own version number each time you commit). Metacello provides the informations wich Monticello packages fit together and should be loaded to provide a full working app (similar to POM's in Maven, but in a specific class file ConfigurationOfXXX where XXX is the components name). You do not need non-Smalltalk versioning tools like subversion unless you want to manage external resources like pictures or database scripts.

Also look at the Hudson/Jenking integration since this will also help you to automate image building and continuous integration.

Fidele

Answer 6

VA Smalltalk has Envy.

Which ever Smalltalk you choose, I think you will really like Seaside.

Dysphoria

Please don't use signatures; as the FAQ describes, your information is already available in your user card to the right. Also, don't assume that everyone knows what Envy is - It seems that this developer did not! I've suggested an edit to address these issues. – Testa

"Mastering ENVY/Developer" By Joseph Pelrine, Alan Knight, Adrian Cho. books.google.com/books?id=ld6E19QIMo4C – Yoshi