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