[Pharo-project] renggli mirror created on smalltalkhub

Dale Henrichs dhenrich at vmware.com
Thu Jul 5 12:50:47 EDT 2012

----- Original Message -----
| From: "Goubier Thierry" <thierry.goubier at cea.fr>
| To: Pharo-project at lists.gforge.inria.fr
| Sent: Thursday, July 5, 2012 7:37:18 AM
| Subject: Re: [Pharo-project] renggli mirror created on smalltalkhub
| Le 05/07/2012 15:59, Dale Henrichs a écrit :
| > | It still shows that the Smalltalk/via Filetree model isn't the
| > | one
| > | git
| > | expects, but we do benefit from it. I'm also not certain git
| > | would
| > | follow class renames.
| >
| > There aren't really any files outside of the properties file that
| > are associated with a class in this model, so there's nothing
| > explicit to track ... the methods in the class will be tracked
| > nicely (as a rename).
| So that's different from the current FileTree format then ? The
| FileTree
| I do use has .class directories.

Not different. .class directories are used, but directories aren't objects in git ... only files are managed ... directory structure is simply reflected in the "name" of the file ... so changing a directory name (rename class) shows up as renaming all of the files under that directory. There isn't an explicit file that represents the class itself other than the properties file in .class directory ... 

| > |
| > | > multiple files makes reading source on disk a bit awkward, but
| > | > that's what we've got the Smalltalk image for ... how many
| > | > people
| > | > out there unzip their .mcz files to read Smalltalk source?
| > |
| > | Me!
| > |
| > | I do open .mcz  files at times; I appreciate the fact it's as
| > | easy as
| > | clicking on it and then search into the produced files.
| > |
| > | The fact that Linux recognize them as zip archives helps, too.
| >
| > Haha...well the directory structure is searchable, too .. just a
| > more complicated incantation:)
| Yes, that's true. Both formats are nice in my opinion: mcz since they
| can easily be carried around and have a nice way of showing version
| and
| developper; and the a file per method, a directory for a class is ok
| too.

Agreed, not perfect, but the current structure is navigable.

| So far, in my experience, all version control systems have to be
| "encaged" in a set of rules of use to fit the work culture of the
| team,
| group or lab. At the moment, I'm not entirely sure of the rules
| followed
| in the Pharo culture, so I'm a bit hesitant to raise issues (and tend
| to
| bring along a small set of changes to be made each time I restart
| from a
| fresh Pharo image, including a few gophers to get the packages I
| need).

Right now we are in the very early stages of learning how to use git with Smalltalk ... FileTree is the first step, but it is clear that we need more work ... 

FileTree is perfectly usable for folks that are comfortable with git and the command line, but it's not for everyone.

We need a bit more tools support ... and development is under way, but not yet fully integrated into the development environment ... we are still gaining experience and in the process of discovering best practices for Smalltalk.

| Maybe a small documentation about how to keep an image up-to-date?
| How
| to deal with slices? A way to extract all the changes on a package as
| a
| change set?

Once we have Metacello support for git/github, then I'll write some documentation ... right now I have a workspace that looks like the following:

Metacello new
  baseline: 'Metacello';
  repository: 'filetree:///opt/git/metacello-work/repository';

Metacello new
  baseline: 'FileTree';
  repository: 'filetree:///opt/git/filetree/repository';

for refreshing my image from the git repositories, but I also may do something a bit more automatic[1], but I haven't quite gotten to that point in my development:)

[1] https://github.com/dalehenrich/metacello-work/issues/33
| In a way, Monticello is very convincing and powerfull (maybe just
| because it works as it is and is integrated), and in others, it's
| annoying to see how more powerfull and better it could be.

There's always room for improvement, but there's not always the time:) 


More information about the Pharo-dev mailing list