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 <
george.herolyants at gmail.com> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20100311/5554c190/attachment.htm