Hi George. Thanks for the proposal. Yes, you have time until tomorrow morning :)
Would be cool to see what other think. Now...do this make sense if we already have SqueakSVN ? which this new project would be better than SqueakSVN or why isn't it worth to continue with SqueakSVN instead of start from scratch ? Is it just because GIT seems to be better than SVN ? Maybe a clarification of this in your proposal will be better so that people like me understand why this project is interesting. Cheers Mariano On Thu, Mar 11, 2010 at 7:27 PM, George Herolyants < [email protected]> wrote: > Hi, guys! > > Here is a project idea for GSoC. Something that, I think, one day came > into everyone's mind. I've just written it: > > --------------------------- > > ++ Pharo/Squeak integration with git/mercurial. > > Source code management is highly important aspect of every software > project. Currently in Squeak/Pharo world developer has very limited > choice of such tools. The only available full-featured SCM tool is > Monticello. Other alternatives such as changesets lack in some areas. > Monticello in its own turn has some disadvantages: it can only handle > Smalltalk code while typical software project has many other artefacts > (represented primarily as files) such as documentation, scripts, > diagrams and so on, which would be nice to have in the same > repository. This project aims to get round these disadvantages by > creating a possibility for developers to use modern distributed source > code management tools, which are popular outside of the Smalltalk > community. The most recognized are git and mercurial. > > **Technical details** > > This project may go different ways towards it's goal, depending on > decisions being made during it. > > Initial steps will be: > * Examining git/mercurial and choose one of them considering > simplicity of API and it's ease of use, supported operating systems on > and other important factors. > * Defining and implementing a file mapping format for the Smalltalk > code structure (classes, methods and so on), in order to support > versioning at the level of separate methods (there is already one > defined by SqueakSVN project so this step may require examining it). > Or examining the ability to avoid such a mapping and store code > directly without needing a working copy on disk. > * Studying how Squeak/Pharo handles system changes (changes of > classes, methods). Then implement handlers for such changes to > translate them to working copy using the mapping or through SCM API. > * (optional but desirable) Implementing Smalltalk interface to the > chosen SCM. It can be based on the SCM's command line interface or on > it's API. These will require using OSProcess or FFI (or writing a > plugin) respectively. > > Additional steps may include: > * Implementing import/export tool for Monticello repositories. > * Implementing simple user interface for the chosen SCM so that > programmer can work with it from within the Smalltalk environment. > Integration with widely used OmniBrowser would be even better. > > In addition to this a local git/mercurial repository can be used > instead of sources/changes files. This will require: > > * Exploring the current mechanism used in Pharo/Squeak to maintain > method version history. > * Replacing it with the developed system which will write changes to > the local git/mercurial repository. > > **Benefits to the student** > > The student will: > * learn about modern source code management systems; > * study their interfaces, both command line and API; > * study Pharo/Squeak internal mechanisms related to handling of > classes and methods changes and storing of method versions. > * get experience in usage of FFI or writing plugins for Smalltalk VM; > * get experience with making GUI in Pharo/Squeak; > * enjoy writing programs in Smalltalk :) > > **Benefits to the community** > > Developers will be able to choose SCM system grounding this choice on > their own preferences. The community will gain access to some famous > source code hosting services such as GitHub or Bitbucket. Among other > benefits it will increase visibility of the community and the > Smalltalk language in whole. It also will lower the entry barriers to > newcomers and as a consequence will help community grow. > > Getting rid of sources/changes files offers potentially unlimited > method version history and avoids so called "condensing changes". And > using local git/mercurial repository for this purpose will make > managing changes more natural and uniform in small (every method > accepting) and in large (changes at the project level). > > ---------------------------- > > I would like to be a mentor (if no one agrees to mentor) or co-mentor, > if you guys don't mind. > Hope it's not too late :) > > > George >
_______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
