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@finworks.biz | To: Pharo-project@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 | |