On 11/7/16 11:30 AM, Thierry Goubier wrote:
Hi Dale,
2016-11-07 12:03 GMT+01:00 Dale Henrichs
<dale.henri...@gemtalksystems.com
<mailto:dale.henri...@gemtalksystems.com>>:
On 11/7/16 7:15 AM, Thierry Goubier wrote:
2016-11-07 11:05 GMT+01:00 Esteban Lorenzano <esteba...@gmail.com
<mailto:esteba...@gmail.com>>:
On 7 Nov 2016, at 10:03, Thierry Goubier
<thierry.goub...@gmail.com
<mailto:thierry.goub...@gmail.com>> wrote:
Hi Esteban,
I cut out the rest, because I agree with all your points,
except for...
2016-11-07 9:55 GMT+01:00 Esteban Lorenzano
<esteba...@gmail.com <mailto:esteba...@gmail.com>>:
[ ... ]
Replacing Monticello with git goes in this direction:
[ ... ]
And this one I don't understand. A smooth, git / iceberg
oriented transition over Monticello/Metacello is perfectly
doable... As Dale explained. A nice Iceberg gui reworking /
making git usable is perfect.
Well… I disagree with this.
All my experience says the opposite: this is a convenience
usage that in the long way does not match (the thing that we
simulate mcz packages do not work… and makes things a lot
harder to maintain later).
Nico has worked a lot on this, maybe he has something to say.
I'd like to. Simulating mcz? That I don't get it.
Thierry, If I'm not mistaken, Esteban is referring to the fact
that in FileTree we are still using Monticello to do the load of
the packages and even when we are running metadataless, we end
creating fake meta data to simulate an mcz ... you and I have had
conversations about ways to eliminate this "requirement" because
it is meaningless in a git context ...
Yes, this I understood. I do believe that what I suggested at one
point (have the ability to compare versions with an 'isAncestorOf')
would be very nice for that transition (work in mcz as well as on git
with/without metadata).
II think that the work that you did with gitfiletree was very
influential in making git a realistic option for the Pharo community and
I think that the choices you made were excellent, but I think that for a
transition it is important that git be presented as itself more fully
and expose some of the features that set git apart
(project/package/class/method diffs; multi-package commits; etc.) ...
but I also feel that Monticello does not need to be diluted --- the
existing Monticello tools should remain in place for the forseeable
future ...
With the work that Richard Sargent did on the
CypressReferenceImplementation, I would prefer to say that Cypress
can provide an Alternative to Monticello rather than replace it
... the CypressReferenceImplementation includes a package loader
so it isn't necessary to convert Filetree format on disk to Mcz
format in the image --- without all of the ancestry, "latest
version stuff" and package-cache the loading process becomes much,
much simpler...
I think that both Monticello and Cypress can live together in the
image ...
For me, MC is also the code / diff model behind: will Cypress rewrites
all that too?
Well Cypress is not that much of a rewrite ... Cypress definitions are
closely based upon the Monticello definition model... snapshots and
loading based on comparing the snapshot of the repository against the
snapshot of the image are also closely based on Monticello ... The
differences are in the fact that Cypress packages do not have ancestry,
author names or version numbers:
- the ancestry and author is recorded and managed by git (or svn or hg)
- there is only one version of a package in a fieltree repo, so there
is no
need to sort packages by version number to fine the "latest version"
So Cypress is more of a "take all of the really good parts of Monticello
while dropping the bits that are handled better by git" than it is a
complete _rewrite_ ...
I have created a version of Metacello that uses Monticello OR
Cypress and I expect to eventually (in the next several months ---
it doesn't take that long, but I've got other things on my plate)
to have a version of Metacello that uses Monticello AND/OR Cypress
again I think that smooth transitions (that may take a long time)
are better supported in this fashion than to draw a line in the
sand and force the usage of one OR the other ...
As long as Cypress behaves as a MC repository and fits into the same
API, I really don't see where is the difficulty. As we are saying now,
adding a type of repository / emulating the MC overall API is no real
difficulty in itself and isolates one from all the project management
issues (because that means Metacello, ConfigurationOf and BaselineOf
just keep working as usual).
There are api differences between MC and Cypress ... MC has ancestry and
package numbers while Cypress does not ... but I don;t think that these
are major items ... I have yet to try to merge MC and Cypress in the
same Metacello code base and I have yet to look closely at the
requirements for Cypress Package Browser tool, but I know that the
Cypress Package Browser will be much simpler ... But the goal for
Metacello is that individual developers will be able to choose the
repository/package model that best fits their work flow and portability
needs ...
We need to get the MC repository API to evolve a bit, in part to
handle the "save multiple packages, do one commit without using
package dependencies." required now, and also to expose more of the
repository organisation (remotes, branches) for the GUI above. And
remove some of the things saying "I'm MC trying to do Metacello's job".
yes I think this is the area where a Metallo Project Browser comes into
play. The technology for committing the dirty packages in a a
ConfigurationOf has been around for quite awhile, but a tool that
unifies the "multi-package" commit for ConfigurationOf and BaselineOf
hasn't popped out of the wood work ...
What is a bit annoying, really, is this talk of rewriting everything
where some of the pieces (the project browsing you're talkin about,
for example) is already there in the image, just not exposed.
Well I am annoyed as well .. I would say that perhaps we are in
screaming agreement ... I've said that I don't think it's a lot of work
to do the project-centric tool. but a project-centric tool that
encompasses both ConfigurationOf and BaselineOf will expose the features
that "are already there"
I'm trying to code a little something for that... stay tuned for a
screenshot soon.
Cool:)
Dale
