Proposed Smalltalk project directory structure

smalltalkProjectSructure.md

##Monticello Package Structure

The basic idea is to store individual methods in files so that git can manage method-level history. The split between classes and extensions in the snapshot directory is differentiate between classes defined in a package and extension methods defined in the package:

+-Sample-Core.pkg\
  +-snapshot\
  | +-classes\
  | | +-SampleCore.class\
  | |   +-SampleCore.st
  | |   +-instance\
  | |     +-author.st
  | +-extensions\
  |   +-Object.class\
  |     +-instance\
  |       +-isSample.st
  +-.filetree
  +-categories.st
  +-initializers.st
  +-package
  +-version

##Repository Structure

The classic Monticello style is to store all packages in a single directory. The actual name of the directory doesn't matter. The specs in the metacello.st file contains the classic Metacello spec information:

+-sample
  +-core/
  | +-metacello.st
  | +-Sample-Core.pkg\
  | +-Sample-Platform.gemstone.pkg\
  | +-Sample-Platform.pharo.pkg\
  | +-Sample-Platform.squeak.pkg\
  | +-Sample-Tests.pkg\
  +-doc/
  +-license.txt
  +-README.md

##Alternate Project Structure

Packages are distributed across the core, platform, and tests directories. The package structure is the same, but the Metacello spec information is different so that packages can be referenced in the different directories:

+-alternate
  +-core/
  | +-metacello.st
  | +-Sample-Core.pkg\
  +-doc/
  +-platform/
  | +-metacello.st
  | +-Sample-Platform.gemstone.pkg\
  | +-Sample-Platform.pharo.pkg\
  | +-Sample-Platform.squeak.pkg\
  +-license.txt
  +-README.md
  +-tests/
  | +-metacello.st
  | +-Sample-Tests.pkg\

With git, I think that using separate branches for the different platforms makes a lot of sense ... but when you do that it makes sharing fixes between the various branches a bit difficult ... with the standard git merge you to resolve conflicts and accept all changes, but having a branch per platform means that you want to preserve the platform specific differences and only accept the "common" changes ... which requires some discipline and knowledge ...

In the end I think that we need to have some experience with different techniques and pick the one that has the fewest flaws

i forked it (here git://gist.github.com/1997065.git) and changed the name of the directories