[Pharo-project] [squeak-dev] Re: [Smalltalk for small projects only?
otto at finworks.biz
Sun Jan 29 23:03:42 CET 2012
We've built a little package that allows us to save all our source in
git. We've been developing with this for 3 months now, and it's pretty
stable. I put a project on github,
https://github.com/finworks/smallsource that contains some more info
on it. Yes, there's more work to do, but there's hope. The repo
contains some examples that I just saved from the image.
In short, we save and load all the monticello packages on our project
as smalltalk source files. We use git to merge and not monticello. We
use metacello, but watered down to essentially just dependencies.
I just want to say thanks to all you people who put in such great
effort into Smalltalk. We are using Smalltalk to create a business and
are slowly getting somewhere.
We've been using git for about 3 years now. This came from a need to
manage files, such as scripts, resources (images and stuff), documents
and recorded selenium (ide) tests with smalltalk code. So, we just
whacked all of this, including our monticello packages into the git
As you can imagine, storing binary files in a git repo, especially
fairly large packages and lots of integrations / merges / versions,
grew the git repo quite a bit. We also needed to clone the git repo
all over. So we decided to give it a shot and write to files.
It took about 2 weeks to get going and another to sort out some pain,
but the package in the smallsource repo have not changed for 3 months.
We are 5-6 developers on the project, committing numerous times a day.
We currently have about 1100 classes (find repo -type d | wc -l gives
us 2200) and 23500 methods (find . -type f | grep -v "mcz$" | wc -l
gives us 23545) managed in this way.
I'm keen to talk about how we can really "do the right thing" and
solve this source code management monster. I know this approach needs
work (I'll list some issues on the project, that I think needs
attention) and I also realise that there could be better approaches.
Here's another idea: we can map class definitions and method
definitions directly to git objects. Git has a great object model
which will allow us to directly track the complete history of a method
or class definition, with commit details and what not. In a sense, I
feel that a tight integration between a smalltalk environment and git
will be a fantastic solution - something like envy, but on git, with
all the fanciness that comes with git!
The only problem with this is a very tight coupling with git. Do we want that?
More information about the Pharo-project