On 11/7/16 4:52 AM, Esteban Lorenzano wrote:
btw this is pharo-dev discussion, redirecting there.
Esteban
On 7 Nov 2016, at 08:50, Esteban Lorenzano <esteba...@gmail.com> wrote:
We are developing Iceberg… and I know is not enough :)
Which “unifying tools” are you referring ?
The main unifying tool is a Metacello Project Browser (or something like
the tODE project list).
You have a nice tool with the CatalogBrowser (modulo BaselineOf support)
... but you know that already:) but once you load a Project into the
image with the CatalogBrowser it sort of disappears ...
There needs to be a way to see the _projects_ are loaded in the image
... right now you can see the package loaded into the image, and you can
see the dirty packages, but the package is at too low a level
From the project browser you should be able to commit a project ---
which saves all of the dirty packages in the project --- in one commit
for a git project --- all of the dirty packages written in one operation
for mcz packages ...
This project browser can provide the same set of services for an mcz
project (ConfigurationOf) or a filetree project (BaselineOf):
- save
- load -- this is a bit more complicated to explain (I
tried at the Metacello Dr. talk, but more discussion is needed)
- diff -- project level diff over a collection of packages
- commit log -- For ConfigurationOf, list the commit history of the
Configuration.
For a BaselineOf list the commit log for
the git repository
The workflow at the project level is not that different between Mcz and
Filetree, so it is straightforward to work with ...
The unification comes because you can use one metaphor (project) to work
with both Mcz and Filetree ... the underlying implementation will
ultimately...
The next layer of unified tools is when you look at version history, for
a method, you need to provide the ability to view the git commit history
for the method (if stored in git) or the image history ... git commit
hisotry can be provided at the project/package/class/method ...
whereever possible the equivalent mcz/git service should be provided so
that the two systems are on an even par ...
The Monticello Browser and Iceberg GUI's don't go away, because it is
often necessary to do work at the package level, but I think that
putting focus on the project is the key ingredient to success for
integrating git ...
Since git repos are persistent on disk and will be shared ... it is
important that there be a way for developers to easily access the git
repos for projects that have been cloned locally but not yet loaded in
the image itself ... I am really struggling with getting how important
this point as this is the also a point that ties a Catalog Browser and
Project Browser together
I've been using this approach for several years now and once you have
the tools and can see at a glance what's "going on in your image" it is
fun to work in a mixed environment ... all of this frustration that is
bubbling on the list is largely due to not having these missing tools
and underlying support --- I think ...
I have followed very close your TOdE development… in a moment I was planning a
migration of it for pure-pharo, just… lack of time as always and then later we
started iceberg.
Yes, I have intended to do a port of tODE to Pharo, but of time is the
killer :)
now, we are in the process of defining a process ;) who works for pharo and is the
moment to build the bridges we need, but in general I think that staying "with
a foot in two boats” can just work during a very short lapse of time, after that,
the stream continues going and if you do not finish your jump into one of the boats
you will be very fast in the water.
Yes but the two boat environment will last years ... it has taken almost
5 years for filetree to start to be used regularly ... and with the
Metacello Project Browser approach the transition will not be nearly as
painful, besides I think that the project-centric tools set is required
when work with git....
What I mean is that we can help any transition, but at the end there is no way
of having a “nice, coexisting” ecosystem: we will have one OR the other, or
something that does not works at all, but we will not have seamlessly one AND
the other (which does not means people using monticello will be forced to use
git tools or vice-versa, just that you will need to chose one… right now many
(many for real) of our problems come from the attempt of keeping our git
support behaving as regular monticello…
As I say, I think that monticello/filetree can be abstracted away at the
Metacello Project Browser level ... a commit of dirty packages writes
all the dirty packages for the project in the appropriate repository ...
BaselineOf are filetree and ConfigurationOf are mcz ... it doesn't take
a whole lot of code to smoothly handle both projects --- as I've said, I
have code in tODE that can be looked at for the key trickery and then
re-implemented within Pharo without too much trouble ...
Then the choice does not have to be made between supporting
ConfigurationOf and BaselineOf as both are supported ... eventually a
developer may choose to build an image that does not include
ConfigurationOf and Monticello support --- but both are needed for at
least the next several years
and that way of doing has a limit. A limit I think we already passed.
Anyway, if you can list what you think we will need for the transition, I will
be very glad to see what we can do :)
the presentation that I made last Wednesday really covers the most
critical things that I think are required ... Metacello Project Browser
and load specs are the big ones ... presumably a Project Browser/code
browser that allows you to read code at the project level to augment the
existing package level code browsers with the commit history integrated
at project/package/class/method level ... project level diff tool --
multi-package diffs in one window ... and a git merge tool that does a
three-way merge within the image ...
Dale
