Wow guys, it is nice for me to see that this thread raised some fruits
already and it seems it will even more in the future :)

Best regards
Janko

S, Dale Henrichs piše:
> Otto,
> 
> 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...
> 
> Dale
> 
> ----- 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
> | 
> | 
> 
> 

-- 
Janko Mivšek
Aida/Web
Smalltalk Web Application Server
http://www.aidaweb.si