[Pharo-project] [squeak-dev] Re: [Smalltalk for small projects only?

Dale Henrichs dhenrich at vmware.com
Mon Jan 30 18:33:44 CET 2012


This looks very interesting! Since you are still using Monticello, I think it should be very straightforward to add the file tree repository type to Metacello as a starting point, although I'm sure that more support is needed than just that..

I am in the middle of working on the next release for Metacello, so now is a good time to integrate smallsource support into Metacello, please drop me a line and give me your thoughts on the direction you think things need to go...


----- Original Message -----
| From: "Otto Behrens" <otto at finworks.biz>
| To: Pharo-project at lists.gforge.inria.fr
| Sent: Sunday, January 29, 2012 2:03:42 PM
| Subject: Re: [Pharo-project] [squeak-dev] Re: [Smalltalk for small projects	only?
| Hi,
| 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
| repo.
| 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?
| Thanks again
| Otto

More information about the Pharo-project mailing list