On 11/7/16 7:36 AM, Esteban Lorenzano wrote:
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).
Well, I don't think that Iceberg is doing package loads and I don't
think that Iceberg will provide support for mcz repositories so I still
think there is a need for this Metacello Project Browser ... the
Metacello Project Browser would delegate to Iceberg for all of the
services that it does provide.
The Metacello Project Browser would not be a purely git/github tool ...
Metacello Projects are repository format neutral so svn, hg, etc. would
be equally supported from the Metacello Project Browser ... the standard
set of operations: save/load/diff/log are needed for all different
repository types ...
I don't think it's a lot of work to implement the Metacello Project
Browser tool and it is important that there be one place to look for and
manage the projects loaded in image .... this is the "unifying" bit ...
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 :)
Well I am specifically referring to this issue[1] and this comment by
Guille[2] and Nico[3]. If Iceberg isn't going to load packages, then you
need a tool that will load a package ...
and as I say above this tool must work with ConfigurationOf and
BaselineOf for svn, hg, etc. repositories ...
[1] https://github.com/npasserini/iceberg/issues/184
[2] https://github.com/npasserini/iceberg/issues/184#issuecomment-254139549
[3] https://github.com/npasserini/iceberg/issues/184#issuecomment-257865003
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).
again in tODE, the Metacello Project Browser (aka project list) allows
one to view projects that are cloned to local disk but not loaded in the
current image ... note that I an using the term "project" not git
repository ... the catalog browser defines "load specs" for projects ...
but the developer is not able to control how the project gets loaded ...
a better more flexible catalog browser would actually download spec
objects into the Metacello Project Browser and allow developers to
adjust the "load spec" for their environment, share this "load spec"
with the other images in the "image cluster" and use the "load spec" to
clone github projects to local disk and then load from the Metacello
Project Browser ...
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 :)
I would agree that not far is fair and I don't think that there is a ton
of work to be done, but it is work that needs to be done ... so going
the last little bit is necessary ...
Nico is open to discussion, but I am not sure that all of the things
that need to go into the Metacello Project Browser belong in Iceberg ....
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.
oops now you tell me:)
Dale
