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

Stéphane Ducasse stephane.ducasse at inria.fr
Mon Jan 30 05:46:45 EST 2012


Hi otto

how to you deal with conflict due to the for example move of methods due to file out?

Stef



> 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-dev mailing list