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