Yes, 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? Dale ----- Original Message ----- | From: "Frank Shearar" <frank.shearar@gmail.com> | To: Pharo-project@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@gmail.com> wrote: | >> Gitocello [1] 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 [2][3][4]. | >> | >> 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. | >> | >> | >> [1] https://github.com/timfel/gitocello | >> [2] https://github.com/frankshearar/Unification | >> [3] https://github.com/frankshearar/PersistentUnionFind | >> [4] 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 | definitely | want method-per-file. You get method history for free! | | frank | |