Hi Dale, 2016-11-07 12:03 GMT+01:00 Dale Henrichs <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>: > >> >> On 7 Nov 2016, at 10:03, Thierry Goubier <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>: >> >>> [ ... ] >>> >>> 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). > > 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? > > 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). 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". 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. I'm trying to code a little something for that... stay tuned for a screenshot soon. Thierry > > Dale >
