What I really like in SqueakSVN is an integration of repository management directly into a browser. If other tools like Monticello would follow the example, life for us poor coders would be much easier, IMHO.

Not to mention us who need to switch daily from different dialects. Code repository management directly from browser is for instance one of strengths of VisualWorks over Squeak. And as SqueakSVN guys demonstrated, this is not too hard to introduce in Squeak as well.

This also raises another question: isn't a Squeak problem more usability of existing code management tools than their fundamentals?

Just few my thoughts..

Janko

Giuseppe Luigi Punzi wrote:

Looks interesting.

Congratulations.

Michael Perscheid escribió:

...

Hi list,

I am very proud to announce "SqueakSVN".

SqueakSVN is our last bachelor project and joins Squeak with version control offered by Subversion. Squeak developers take advantage of team programming and the benefits of Subversion's growing popularity and support.

More details can be found on our web pages.

• Project Description:

http://www.swa.hpi.uni-potsdam.de/projects/ssvn/index.html

• Source Code Download:

http://www.swa.hpi.uni-potsdam.de/projects/ssvn/media/SqueakSVN.sar

• Demonstration Video:

http://www.swa.hpi.uni-potsdam.de/projects/ssvn/media/ssvn_en.mp4

Best Regards,

Michael Perscheid on behalf of the Software Architecture Group Hasso-Plattner-Institut, Potsdam

2008/9/16 Eliot Miranda eliot.miranda@gmail.com:

Yesterday I watched Linus Torvalds talk on G IT at Google. Once you get past his obnoxious public persona there is meat here

Look at the rate of change in Linux. A project this huge and critical changing so fast. And this with files, C and text editors.

http://www.youtube.com/watch?v=L2SED6sewRw

Cheers Philippe

Hi Avi,

On Tue, Sep 16, 2008 at 11:55 AM, Avi Bryant avi@dabbledb.com wrote:

On Tue, Sep 16, 2008 at 9:57 AM, Eliot Miranda eliot.miranda@gmail.com wrote:

...

Yesterday I watched Linus Torvalds talk on G IT at Google. Once you get past his obnoxious public persona there is meat here, and its well worth

the

...

1 hour 10 minutes holding one's nose. I think he's right on distributed version control and so would like to see Monticello GIT integration. One

of

...

GIT's features that I think will be most synergistic with Smalltalk is

that

...

it is content addressable. That is, GIT can track the history of a

function

...

even if it moves from one file to another. The system isn't a file tracker, it is a content tracker (in fact, a

content

...

addressible file system). This removes lots of issues in the mapping of Smalltalk methods to whatever the SCM system manages. In GIT there would

be

...

no problem mapping a class to a file. One could still track the history

of

...

a method within it with ease and GIT would still transmit only deltas,

not

...

the entire file, when a part of the method changed.

Yes, see my posts here:

http://lists.squeakfoundation.org/pipermail/squeak-dev/2008-June/129602.html

http://lists.squeakfoundation.org/pipermail/squeak-dev/2008-June/129605.html

Git is modular enough that one could pretty easily, I think, replace its directory-of-files <=> content-tree mapping with a smalltalk-image <=> content-tree mapping and leave the majority of the system intact.

Avi

In http://lists.squeakfoundation.org/pipermail/squeak-dev/2008-June/129602.html you state

I personally believe that we're better off with Smalltalk-specific version control, but if someone *is* looking at integration with more mainstream tools, I would strongly suggest they start with git rather than SVN.

Avi

and I want to emphatically agree with you that we want integrated Smalltalk-specific version control. Lets say integrated Smaltalk-centric rathe rthan Smalltalk-specific because there is benefit in other tools & systems being able to access the source repository's contents without using Smalltalk (e.g. web serving, extracting documentation, bootstrapping and I'm sure much more). But none of this prevents using Git as a back-end. Git seems to have several key advantages (that I didn't mention at first; they're in the talk) that we can use.

First, being distributed (based on divergent replicated repositories) there is no centralisation, no dependency on a server which, if it goes down, one can't work without. There is much higher performance because data is local (until one merges by pulling from other repositories). Second, there is protection against corruption (actually corruption detection) because contents are thoroughly check-summed. Most importantly content-addressability means mapping of Smalltalk to files is easier and not much of an issue.

But I'm not sure I buy the mapping of an image to the repository. I would rather browse packages than images (e.g. a packages subdirectory containing a directory per package) and I still want the changes file for crash recovery. But thats a tension right there. Does one keep Smalltalk structures like the changes file and their support or go the whole hog and just use Git for all source? Personally I want to keep as many of the tools in Smalltalk as possible so I can fix and extend them as I'm working. A large wadge of C should be kept in the back ground as much as possible. Its a file system after all.

Eliot

On 17/09/2008, at 9:10 AM, Eliot Miranda wrote:

But I'm not sure I buy the mapping of an image to the repository. I would rather browse packages than images (e.g. a packages subdirectory containing a directory per package) and I still want the changes file for crash recovery. But thats a tension right there. Does one keep Smalltalk structures like the changes file and their support or go the whole hog and just use Git for all source? Personally I want to keep as many of the tools in Smalltalk as possible so I can fix and extend them as I'm working. A large wadge of C should be kept in the back ground as much as possible. Its a file system after all.

I've been working on GIT integration for some time, and I have a working system called MirrorImage that I have blogged about. It does use source files, although my thinking is that the fact that some ST artifact may be reified as a text stream is simply an API issue - text being a type, and the fact that it may be transfered on disk is equivalent to a parameter passing convention. I don't see what the big deal is here - as long as the domain mapping is bidirectional under all the transformations that GIT/Bazaar etc makes.

When you compare VW and Squeak, one exemplar difference is in how overrides are handled. In VW they are up-front, which is a result of VW's emphasis on it's packaging system as a means of system construction and partitioning.

IMO though, VW doesn't go far enough. MirrorImage reworks how classes are constructed from fragments, e.g. how different packaging units are combined to make up the definition of a class from attributes such as variables, traits and other properties, as well as methods. This includes not only incremental additive construction including ordered replacement/overrides, but subtractive and transformative construction. GST makes some steps in this direction by allowing you to incrementally add instance variables in extensions.

The issue of system construction, at all levels of granularity, packaging, modularity, and version control, are IMO not orthogonal, and the greatest advance comes from considering them holistically.

Antony Blakey ------------- CTO, Linkuistics Pty Ltd Ph: 0438 840 787

If you pick up a starving dog and make him prosperous, he will not bite you. This is the principal difference between a man and a dog. -- Mark Twain

Keith Hodges wrote:

Git isnt the only game in town, there is also Mercurial and Bazaar. Having tried both I prefer Bazaar. Its windows support is great.

I version control my images using Bazaar. We could improve the image format to ensure that diffs work efficiently. I tried normalizing object pointers to a known base address as a starting point. However we could be cleverer I think. (One of the Bazaar devs is a squeaker)

Changing the base address might make loading slower.

Git has filters that allow one to perform bidirectional transforms between the data that is on disk and the data that is in the working tree. People have used to store openoffice files uncompressed, so that diff works on them too.

Do Mercurial and Bazaar have anything like that?

Paolo (who uses git for GNU Smalltalk)

Bert Freudenberg wrote:

Am 17.09.2008 um 07:47 schrieb Paolo Bonzini:

...

Keith Hodges wrote:

...

I tried normalizing object pointers to a known base address as a starting point.

Changing the base address might make loading slower.

Actually, it makes it faster.

Yes, but that address might vary between systems. I interpreted Keith's sentence as "normalizing the base address to zero", not to something that is likely to be available the next time around.

If the VM saves the objects with the current base address, it would probably choose an address that is likely to be available the next time around, but it might be different from what is under version control.

Anyway, with direct object access (no OOP table) there is a fundamental problem that makes diff encoding of images almost impossible. If an object dies, everything after it is compacted and changes its address. If you have an OOP table, the objects are referenced through something that is never compacted, but if objects are accessed directly then every pointer in the image is changing.

Paolo

On Wed, Sep 17, 2008 at 8:24 AM, Bert Freudenberg bert@freudenbergs.dewrote:

Am 17.09.2008 um 17:10 schrieb Paolo Bonzini:

Bert Freudenberg wrote:

...

...

Am 17.09.2008 um 07:47 schrieb Paolo Bonzini:

Keith Hodges wrote:

...

...

I tried normalizing object pointers to a known base address as a starting point.

Changing the base address might make loading slower.

Actually, it makes it faster.

Yes, but that address might vary between systems. I interpreted Keith's sentence as "normalizing the base address to zero", not to something that is likely to be available the next time around.

You can give a desired address to mmap(). We might find one that is likely to work on all systems.

If the VM saves the objects with the current base address, it would

...

probably choose an address that is likely to be available the next time around, but it might be different from what is under version control.

Anyway, with direct object access (no OOP table) there is a fundamental problem that makes diff encoding of images almost impossible. If an object dies, everything after it is compacted and changes its address. If you have an OOP table, the objects are referenced through something that is never compacted, but if objects are accessed directly then every pointer in the image is changing.

As long as the garbage collector does not change the order of objects, the vast majority of oops in a saved image will not change even in a direct-pointer model with a fixed base address. Also, I've been thinking about freezing the lower part of the object memory to speed up gc - it makes no sense to always trace from the very beginning when most of the objects there are never modified (classes etc.). Something like perm space in VW ...

You know that's not how the GC works in incremental (high frequency) mode, right? The GC starts from young space using the rootTable as roots.

Further, when the GC does a full GC it does a full trace (necessary) but only compacts from the lowest free. You could easily simulate perm space simply by adding a new generation, e.g. middleAgedStart. But the store check would be 1 comparison against a global more expensive (i.e. nearly twice as expensive, at least in code size).

• Bert -

As long as the garbage collector does not change the order of objects, the vast majority of oops in a saved image will not change even in a direct-pointer model with a fixed base address.

Unfortunately, that should be true for casual usage but not for development. The subclasses instance variable of Behavior is an Array... I guess I don't need to explain further...

Paolo

Bert Freudenberg wrote:

Am 18.09.2008 um 10:08 schrieb Paolo Bonzini:

...

...

As long as the garbage collector does not change the order of objects, the vast majority of oops in a saved image will not change even in a direct-pointer model with a fixed base address.

Unfortunately, that should be true for casual usage but not for development. The subclasses instance variable of Behavior is an Array... I guess I don't need to explain further...

Sure - I'm thinking of app deployment with a read-only image.

Ah, okay, I was thinking of app development since we're talking about VCS here.

Paolo