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