On Tue, Sep 16, 2008 at 4:40 PM, Eliot Miranda <eliot.miranda at gmail.com> 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.

Ah, agreed about browsing packages.  I just meant, you can have
Smalltalk code directly map a package from the image into a git
repository, rather than having the intermediate step of spitting out a
bunch of "source" files, which is what SqueakSVN does.

> 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 think we're pretty used (from MC) to the duality of .changes and
version control, and it works reasonably well - I wouldn't object to
removing the changes file entirely but it seems like a lot of work to
do so.  As for keeping as many of the tools in Smalltalk as possible -
well, there's a continuum there, from MC or MC2 where all the
important bits are in Smalltalk, to SqueakSVN where most of the
interesting stuff is hidden behind an API or external processes.  What
I envision with Git would be somewhere in between, where you would
have Smalltalk code directly manipulating the Git data structures, but
would still spend a lot of time using the command line git tools for
stuff that didn't make sense to reimplement in Smalltalk.

Avi