[Pharo-project] renggli mirror created on smalltalkhub
dhenrich at vmware.com
Wed Jul 4 11:50:51 EDT 2012
FileTree is actually modeling the Monticello definition structure on disk ... git does a very good job of tracking changes at the method level when methods are stored in separate files (it recognizes method renames) ... multiple files makes reading source on disk a bit awkward, but that's what we've got the Smalltalk image for ... how many people out there unzip their .mcz files to read Smalltalk source?
----- Original Message -----
| From: "Frank Shearar" <frank.shearar at gmail.com>
| To: Pharo-project at lists.gforge.inria.fr
| Sent: Wednesday, July 4, 2012 6:01:19 AM
| Subject: Re: [Pharo-project] renggli mirror created on smalltalkhub
| On 4 July 2012 13:52, Camillo Bruni <camillobruni at gmail.com> wrote:
| >> Gitocello  takes this approach. While Tim Felgentreff started
| >> it to
| >> ease porting between Squeak and GNU Smalltalk, it works just fine
| >> as a
| >> new MC backend. I use it a fair bit .
| >> Mind you I _haven't_ tried collaboration with it. If you had
| >> conflicts
| >> you would need to use git to address the conflicts, and you can
| >> have
| >> "inter-method" conflicts which are impossible with FileTree. (In
| >> other
| >> words, conflict markers could start in one method and end in
| >> another.)
| >> Probably the chunk format's date stuff would get annoying, as
| >> well.
| >>  https://github.com/timfel/gitocello
| >>  https://github.com/frankshearar/Unification
| >>  https://github.com/frankshearar/PersistentUnionFind
| >>  https://github.com/frankshearar/Zippers
| >> frank
| > ah nice, though you went for the one file per class approach.
| > Which I think is not the best solution for pharo.
| > For instance I want to replace the .changes / .sources file with
| > one git repository which allows you to simply load new changes on
| > demand and find methods with a minimal effort :)
| Well, "you" is "Tim", but sure. Yes. I like Gitocello's approach
| because I can use GitHub without having 1000 mini files. I also like
| FileTree's approach of method-per-file, because that's the natural
| granularity of Smalltalk code. I seem to recall Sean DeNigris showing
| a screenshot of vim that "stitched" multiple files together to solve
| the "FileTree problem". And I'd say that yes, if you changed the
| .changes file into a repo (which is an awesome idea), you'd
| want method-per-file. You get method history for free!
More information about the Pharo-dev