There is a Repository framework as part of Ginsu. Each repository has an access method and an associated repository accessor. Unfortunately, Ginsu only implements the file based repository accessor. It also appears to only hold revisions of SqueakFileIn type in the Ginsu release. Though I do see bits of code that promise that it should not be too difficult to revision packages, clusters and subsystems.

Entities in a repository have a type and a name and a revisionTree. This tuple identifies the location of a particular revision in the connected repository. What would be required are other repository accessors to handle different storage regimes (eg cvs, svn, ftp. sql). Of course, a limitation of this approach is that while it may target many backends, it may not expose some of their niftier features.

I too have dusted off Ginsu, and am starting a little experimental spike to see how far a few friends and I  can go in our spare time. 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.

John Sarkela

On Mar 12, 2010, at 3:04 AM, John M McIntosh wrote:

> 
> On 2010-03-11, at 11:18 PM, George Herolyants wrote:
> 
>> Oh, sorry, here it is:
>> 
>> 
>> 
>> ++ Pharo/Squeak integration with git/mercurial.
>> 
>> * 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.
> 
> Ok, sitting on my desktop here is the work from "The squeak world tour", Ginsu
> via Joseph Pelrine and John Sarkela. 
> 
> I think this might have some relevance to the project since it :
> 
> I'll quote Joseph:
> 
> "maps classes and methods (or better, their semantic definitions) into Subsystems, each of which can have a separate execution environment, allowing remote image work, alternate compilers, passive images, tethered compilation, etc. You can work on and validate code that's not installed in the image."
> 
> But it is missing the repository backend. 
> 
> 
> --
> ===========================================================================
> John M. McIntosh <johnmci at smalltalkconsulting.com>   Twitter:  squeaker68882
> Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
> ===========================================================================
> 
> 
> 
> 
>