On 2012-07-04, at 15:02, Torsten Bergmann wrote:

...

can you think of any feature we could have now we couldn't with Git?

With Squeaksource/Monticello I'm currently able to have a web based Smalltalk browser. So I dont have to fire up an image to digg into other peoples code.

I expect that could be done with Git hosted projects too - but requires some work and another server providing the ST-IDE like feeling. So the "Smalltalk like user experience" is not available out of the box on the usual hosting services. This is a small step backward.

One thing is a must: the usual handling of code should be preserved. As far as I understand this is the case even with an GIT-based MC!?

Some questions:

1. Usually Git requires a local git installation. Is the Git-MC binding a pure ST solution working on all platforms or does it require some native support?

FS-Git is a pure ST implementation to manipulate git repositories. Currently we lack of support for the git-protocols since we don't have ssh support in the image :)

2. Can I setup an own local repo in a simple directory similar to Monticello or will it require some github stuff.

github has nothing to do with git, it's just a free hosting service (such as gitorious). So yes, you can run evreything locally

3. Will the local package cache still contain MCZ's?

NO! it will store either 1 file per method or 1 single file per class depending on which strategy you chose. But files are directly accessible no zip madness

On the other hand hosting on file based versioning systems would make source code indexable for search engines and could raise Smalltalks place in the (stupid) TIOBE index ;)

it could and it will! For instance check the Pharo-2.0-Core fileout: https://github.com/PharoProject/pharo-core that is now used on ohloh to track progress :)

I could imagine both: file based repos (Git) as well as ST-only solutions as long as they work and reliable. At the end of the day it's nothing more than a different representation of code.

eventually everything is file-based. MC does it using mcz which was a simple and good solution back then but does not scale. Git is a filesystem on it's own with very nice properties.

An ST-only server side solution would at least allow for easy customization and allow the community to adapt the hosting to its needs.

with git there is no need for that. Git can use almost any source as remote repository: - any mounted volume - a git repository somewhere on a server accessible via ssh

embedded replies ----- Original Message ----- | From: "Torsten Bergmann" <astares@gmx.de> | To: pharo-project@lists.gforge.inria.fr | Sent: Wednesday, July 4, 2012 6:02:06 AM | Subject: [Pharo-project] renggli mirror created on smalltalkhub | | >can you think of any feature we could have now we couldn't with Git? | | With Squeaksource/Monticello I'm currently able to have a web based | Smalltalk browser. So I dont have to fire up an image to | digg into other peoples code. | | I expect that could be done with Git hosted projects too - but | requires some work and another server providing the ST-IDE like | feeling. | So the "Smalltalk like user experience" is not available out of the | box on the usual hosting services. This is a small step backward. | GitHub has a feature called gh-pages[1] that allows you to define a project-specific web-site embedded in your project and hosted by GitHub. I leverage that feature to provide an Amber-based view of my GitHub projects[2]. Click on the `Browse the GitHubPage class` button to bring up the Amber Smalltalk browser:) ... hosted by GitHub and your browser. There is a web-based api[3] for accessing the the information in a github project that could be leveraged for providing Smalltalk brower for the packages in a GitHub project. Amber already understands the FileTree package structure[4], so it just a simple matter of programming ... in Smalltalk! [1] http://pages.github.com/ [2] http://dalehenrich.github.com/ [3] http://developer.github.com/ [4] https://github.com/CampSmalltalk/amber-cypress/blob/master/README.md | One thing is a must: the usual handling of code should be | preserved. As far as I understand this is the case even | with an GIT-based MC!? | | Some questions: | | 1. Usually Git requires a local git installation. | Is the Git-MC binding a pure ST solution | working on all platforms or does it require some native | support? For direct project development git/mercurial/svn would be required. To the extent that FS-Git[1] supports direct access to GitHub (I believe that level of support is planned) then no local installation would be required. I am adding GitHub support to Metacello (in the form of a Monticello Repository[2]) and it downloads a zipped copy of the directory structure from GitHub directly (using curl via OSProcess at the moment), so consumers of a project do not need to have git installed. [1] https://github.com/dalehenrich/FSGit [2] https://github.com/dalehenrich/metacello-work/tree/master/repository/Metacel... | 2. Can I setup an own local repo in a simple directory similar | to Monticello or will it require some github stuff. The FileTree format is directory based and does not depend upon git in any way ... you can use svn, mercurial to manage the directory contents ... I am highlighting git/github because it is a complete solution, but over time I expect that svn support can be added as well as support for alternatives to github ... | 3. Will the local package cache still contain MCZ's? It should ... I'm not completely familiar with how packages get added to the package cache and it appears that the FileTree packages aren't magically added to the cache[1] ... [1] https://github.com/dalehenrich/filetree/issues/42 | | On the other hand hosting on file based versioning systems | would make source code indexable for search engines and | could raise Smalltalks place in the (stupid) TIOBE index ;) No kidding ... Smalltalk is currently #44[1] on GitHub and when I started in January it was #41... The HollingBerries project[2] is a good example of a way to get exposure to the 1 million developers on GitHub. I submitted my source as a single file, because I wanted it to be readable by non-Smalltalks ... if you call chunk format readable:) For my take, I avoided using conditionals ... #detect: was as close as I got:), I encourage other folks to contribute their approach. [1] https://github.com/languages/Smalltalk [2] https://github.com/apauley/HollingBerries | | I could imagine both: file based repos (Git) as well as | ST-only solutions as long as they work and reliable. | At the end of the day it's nothing more than a different | representation of code. | | An ST-only server side solution would at least allow for | easy customization and allow the community to adapt the hosting | to its needs. All good points! Dale