Re: [Pharo-project] [GSoC] Idea: Pharo/Squeak integration with git/mercurial.

2010/3/11 Randal L. Schwartz <[hidden email]>:

> I believe someone has already written Smalltalk code to parse
> the git object tree.  I forget where I heard it, but I definitely
> went "cool!" in response.

Yeah! I've just found it here
http://permalink.gmane.org/gmane.comp.lang.smalltalk.squeak.general/142806.
So as I already mentioned the idea isn't new :) And some people did
real progress on the issue, while it was only in my "to look at" list
with possible transition to the "todo" list. :)

Maybe I should ask the author of it?

Oh, sorry, here it is:

++ 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 this and some other
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.

There is already SqueakSVN project but it aims to SVN integration. SVN
is classic client-server SCM. But nowadays this kind of SCM's become
less popular, while popularity of distributed SCM's (such as
git/mercurial) is still growing. It is also crucial for open source
projects like Pharo/Squeak to have distributed SCM to ease development
process. Monticello is highly distributed and the new SCM must be
distributed as well to successfully compete with Monticello. So
git/mercurial fits this goal very well.

**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. There's also pure Smalltalk

implementation of Git storage format on SqueakSource, so this step

will require examining it as well.
* 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).

This, of course, all points back to the work that was done on the Team/V product. Which, IMHO, is significantly better than any of its successors and preferable to its predecessors.