[Pharo-project] [squeak-dev] Re: [Smalltalk for small projects only?

Steve Wart steve at wart.ca
Sun Jan 29 17:42:59 CET 2012


The idea of building the git workflow on top of metacello strikes me as
being somewhat ambitious.

To do merge properly (which is one of the huge strengths of git), using a
single .gz file seems likely to be extremely complex.

clone is just copying a .gz file?

pull/push are ftp upload/download of entire .gz file? git has some safety
features that would be tricky to implement on top of metacello I think

branch and checkout operations in git are crazy fast because of the clever
model it uses

monticello/metacello have the advantage of cross dialect support
(Squeak/Pharo/GemStone and VW to some extent), but it seems the semantics
may not be rich enough.

Of course this is just an impression. If someone has some more detailed
thoughts I would be keen to hear them.

Thanks,
Steve

2012/1/28 Dale Henrichs <dhenrich at vmware.com>

> Janko,
>
> Metacello itself needs work to make it usable by groups of developers ...
> the lack of merge capability is a real hindrance to being able to have
> multiple folks work on the same project and use Metacello ...
>
> I imagine that a Metacello configuration is the moral equivalent of a git
> repository. It should be possible to find "moral equivalents" of the
> various git operations: clone, push, pull, branch, checkout, merge, commit.
> It is something that I will be looking into in the not too distant future,
> since I want to improve the usability of Metacello for groups of developers.
>
> I agree that integrated tools is another area that needs attention....
> when it is time to commit your work there are just too many different
> windows and browsers that you have to monkey with to save your work ...
>
> Another area that shouldn't be neglected is the notion of basing things on
> a minimal core image and automated builds for individuals ... We've got
> folks doing good things with Jenkins but I sense that with each
> installation there are things that still need to be customized in the build
> process itself. It should be dead simple, like compiling a c file when you
> know the path to an image...
>
> I think we may focus too much on the in-image tools and not enough on the
> external tools that are just as important.
>
> We need to make it easy for a developer (in a team of developers) to check
> out a version of a minimal1 image, do a reproducible build of the correct
> version of the project, then fire up the image and do his or her
> development thang, commit/push/pull/merge/bang and then the next developer
> does  pull/merge/build/boom to pick up the changes for her image and so on
> ... This involves more than just in-image tooling.
>
> Dale
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gforge.inria.fr/pipermail/pharo-project/attachments/20120129/e2486018/attachment.htm>


More information about the Pharo-project mailing list