git, github and metacello scripting api ... Phase1 is nigh

I've gotten to the point where I can start thinking in terms of phases (3 at the moment) of the project[1].

Phase1 will use the Phase1 branch of the FileTree repository[2], which has no outstanding bugs. There are a number of issues for FileTree[3], but they revolve around fine-tuning rather than raw functionality. The current implementation is completely functional.

Phase1 will not have any in-image support for git (that will come in Phase3), so all interaction with git will be from the command line.

Phase will include a basic set of Metacello scripting commands (commit, dirty, load, fetch, find, get, record, register, unregister, updates, upgrade) bits of which can be seen on this whiteboard pic[4].

I have started up writing the specification/documentation for the scripting commands[5] and when I finish the docs, I'll dive right into work on implementing the commands ... The implementation should go relatively quickly, since most of the commands will be based on the MetacelloToolBox API and for those that are not I already have working prototypes.

Phase2 will involve getting feedback from "early adopters of Phase1" and Phase3 will involve adding in-image support and a Metacello GUI.

I am imagining that I will finish up the Metacello scripting commands and Phase1 this week, so I will be interested in volunteers to start doing their Pharo development (only ported to Pharo at the moment) with git and github.

The way the Monticello repositories work, you can freely copy packages from FileTree repositories to the standard Monticello repositories and back, so you won't be completely committed to git/github if you decide to try things out. I've been using this system for weeks and when I'm ready to refresh the "filetree bootstrapping mcz files", I simply use the Monticello Browser to copy the ConfigurationOfFileTree and MonticelloFileTree from the local disk-based repository to the FileTree repository on SS3[6].

The main things that will go on is that you'll be learning git and github...

For me the biggest advantage that I've seen for using git/github as an individual developer is that when I make a multi-package bugfix, the git commit includes changes to all of the packages that were involved in the bugfix and when I use guthub to look at the commit[7] (a fix that involves the Metacello-MC and Metacello-TestsMC packagess), I can easily see the change to the code AND the impacts on the tests in one simple view ...

The "Pro Git Book"[8] is a good resource for learning git and the post "A successful Git branching model"[9] is a goo introduction for applying branches to your projects ...

I've got the intro page written for the Metacello scripting API[5], so you can get a flavor of what is in store right now ... and I encourage you to use the issue list associated with the MetacelloScriptingApiSpec project[10] for making comments and suggestions on the api(which means you should register on github, if you haven't already).

[1] https://github.com/dalehenrich/MetacelloScriptingApiSpec/blob/master/projectPlan.md
[2] https://github.com/dalehenrich/filetree
[3] https://github.com/dalehenrich/filetree/issues
[4] https://github.com/dalehenrich/MetacelloScriptingApiSpec/wiki/Whiteboard
[5] https://github.com/dalehenrich/MetacelloScriptingApiSpec/wiki
[6] http://ss3.gemstone.com/ss/FileTree.html
[7] https://github.com/dalehenrich/metacello/commit/ad2fd1073286bf003d0cce1da34f23204e761728
[8] http://progit.org/book/
[9] http://nvie.com/posts/a-successful-git-branching-model/
[10] https://github.com/dalehenrich/MetacelloScriptingApiSpec/issues