> On 7 Nov 2016, at 11:28, Dale Henrichs <dale.henri...@gemtalksystems.com> > wrote: > > > > 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 …
this is what is provided by iceberg… it still needs some work, but this is precisely what is supposed to do :) (and btw, this is why I disagree with Thierry some mails below). > > 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 … also, this is supposed to be provided by iceberg. > > 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 … Iceberg is not package-oriented. It just show repositories/packages/classes/methods… this is a good way to do it and I do not thing anything is lost like this. You need to take a second look at Iceberg :) > > 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 this is something to think… I do not get what catalog browser can do here (but yes, a way to browse local repositories needs to be provided). > > 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 do not think we are so far from your vision. I think you did not get it Iceberg right… please, take a second look :) now… is true that now everything you say is already done… but this is general orientation :) Esteban ps: all of this is *clearly* not pharo-users but pharo-dev discussion, let’s move there. >>> >>> 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 >
