dalehenrich

  "download HEAD of master branch of the sample project, i.e., download from github, but don't load Sample project into image"
  Metacello new
    project: 'Sample';
    repository: 'github://dalehenrich/sample:master/core';
    get.

  "load HEAD of master branch of the sample project, i.e., download from github, and load Sample project into image"
  Metacello new
    project: 'Sample';
    repository: 'github://dalehenrich/sample:master/core';

dalehenrich

##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

dalehenrich

'From Pharo1.3 of 16 June 2011 [Latest update: #13315] on 23 February 2012 at 2:38:04 am'!
Object subclass: #MetacelloProjectSpecifications
        instanceVariableNames: ''
        classVariableNames: ''
        poolDictionaries: ''
        category: 'MetacelloProjectSpecifications'! 
 
!MetacelloProjectSpecifications methodsFor: 'Sample.source' stamp: 'dkh 2/23/2012 02:34'!
core: spec
    <project: 'Sample.source' package: 'Core.pkg'>

dalehenrich

1. I assume that by moving to a disk-based structure, we are expecting folks to edit and modify directory structure on disk using the shell and standard editors. This means that all information is going to be stored in plain test files. No binary files. Binary files may be stored in the project structure for use by developers, but the mechanisms for loading code into an image from disk must not involve binary files.

2. I assume that we will preserve package structure on disk. This means that at a minimum we must be able to preserve the collection of class and method definitions that make up a Monticello package. This includes traits and any other standard definitions that are currently present in a Monticello package. In practice "preserving the package structure" means that one can load a package from disk and then save the package to disk in another location and the directory structure is "identical". The package loader must be respectful of files and directories that are not part of the official package

dalehenrich

"Note that the the git work has not even achieved alpha, yet, so don't 
bootstrap into an image that you care about:)

Assuming Pharo 1.3"

"Bootstrap filetree code"
Gofer new
    url: 'http://ss3.gemstone.com/ss/FileTree';
    package: 'ConfigurationOfFileTree';
    load.

dalehenrich

  Metacello new
    project: 'Metacello';
    repository: 'filetree:///opt/git/metacello/repository/';
    load.

MetacelloFileTreeConstructor writeJsonFor:'/opt/git/metacello/repository/metacello/Metacello'.

"current target ... make sure that loadedProjects looks right ... getting nil versions in some cases, so it needs work"

Metacello resetLoadedProjects.

dalehenrich

The project is aimed at making it possible for Smalltalkers to use git/svn/mercurial for project/source version control. There is special emphasis on git and github because github provides distributed repositories and and number of very useful features that enhance the development process.

I started this project when I recently realized that it wasn't as hard to do this as I had thought in the past...

Right now the project is based on Metacello, where I am adding a scripting API to Metacello, like Gofer, but aimed at project level operations not package level operations.

Here's a list of sample Metacello scripting API expressions [1].

Here's the directory structure that I'm proposing to be used for Smalltalk projects[2].

dalehenrich

Philippe,

You are not a party pooper ... these are exactly the kinds of questions I'm looking for They are excellent questions.

I'm going to highlight several of your points and then answer:

"keeping the Monticello and git metadata in sync. For example since it's still Monticello there has to be all the Monticello metadata which is laying around in "strange" files ... makes it quite unlikely that you can edit the source with a

dalehenrich

"cd to a likely spot on disk and run the following at a shell prompt (after installing git):

  git clone -b develop https://github.com/Phariverse/PharoCore.git

then set pharoCoreRepoPath below to path to repository directory inside PharoCore git repository.

Finally run the expressions in this workspace to connect your image up to the correct repositories.

"
| pharoCoreRepoPath  metacelloRepository filetreeRepository 

dalehenrich

"run this to remove cruft before saving image for download"
| standardRepos |
standardRepos := #('http://ss3.gemstone.com/ss/Pharo14' 'http://ss3.gemstone.com/ss/FileTree'  
	'http://www.squeaksource.com/OSProcess' 'http://seaside.gemstone.com/ss/metacello' ).
MCRepositoryGroup default repositories do: [:repo | 
	(standardRepos includes: repo description) 
		ifFalse: [ MCRepositoryGroup  default removeRepository: repo ]].