Hi Eliot, thanks for that mail.
2014-12-04 23:59 GMT+01:00 Eliot Miranda <[email protected]>: > Hi Thierry, > > On Tue, Dec 2, 2014 at 10:25 PM, Thierry Goubier < > [email protected]> wrote: > >> >> >> 2014-12-03 4:16 GMT+01:00 Eliot Miranda <[email protected]>: >> >>> >>> Yes, but *I* care about the Monticello metadata. IMO its *better* than >>> the git metadata. >>> >> >> Eliot, you'll have to do better than just IMO on that one. >> > > Quite right. One benefit is that Monticello metadata, at least per-method > time stamps, are available for introspection inside the image. Just today > I was alerted of some bad code by a particular author and it was very > convenient to read all the methods by that particular author, which helped > me find another problem. I also like the free frorm of the middle of > method timestamps; I can and do annotate with labels for specific > refactorings. > I believe Dale will tell you that git will give you the ability to select a particular author work on a per-line basis, per-file basis (method or class, then), etc... Interestingly, the ability to comment at the file level is provided by github (well, in fact, it's a bit finer grained than that: it's commenting on a change in a file which fits your use case particularly well). So this means we could probably do better there. > > Another benefit is that Monticello is amenable for scripting much more > easily than git. I've been working on the SPur bootstrap fro a while now. > It is essentially complete. What the bootstrap does in Monticello is > construct patched versions of four packages, substituting specific methods > with replacements. Each patched package inherits both from its patched > ancestor and the package that was patched (a ladder like structure). This > allows Spur to keep up-to-date automatically w.r.t. Squeak trunk. > But this would also work over a git-based Monticello. And, as you describe it, it probably even been seen as a simple merge (it's a kind of by-hand merge you're doing, basically). This is one of the features I'm waiting Max for: the time he spent dealing with the low-level structure of the .git stuff(*) so that you can do exactly what you describe (or a Monticello merge) and commit that, and have it tracked as such. (*) Honestly, I didn't want to do it myself :( > > I'm also delighted that work like Chris Muller's version server is out > there. This is very nicely integrated to allow me to find out which > package versions contain versions of a particular method or class > definition. > I know that this version server exists, and I hoped that you would point it out, because I believe it is significant. Even if it is not usable in many professional settings, such as mine. As you probably do as well, I know what features are needed from such a server to make it distributed 'à la git'. > > Some of us work with *both*, and have code for going back and forth, so >> the *better*; bah. >> >> I also happens to know how long it takes to parse hundreds of monticello >> metadata files... and I wasn't impressed with the result. >> > > Yes, but this can be reengineered. Most things can be optimized. This > could be with a little effort. What's needed is to generate and maintain > momentum. That's what worries me about git integration. It's a slippery > slope towards giving up Monticello and just using git. And git itself will > one day be viewed as old-hat. Monticello should be easy to keep evolving. > It's in Smalltalk few chrissake. > Hey! You're talking to the guy who spent time making sure his git infrastructure would look and feel perfectly like a normal Monticello repository :) But, having the on-demand version metadata, on-demand creation of a specific history version, the speed at which you sync a remote, the fact that you can commit locally and sync later, the fact that querying for method or class versions is a lot faster... those are things that one should consider when thinking of improving Monticello. > > > >> >>> What's really lacking in Monticello is a) it's not high school so one >>> can't preen in front of the world on github and b) it has no support for >>> external files. Well, a) will be solved by growing up and b) can be solved >>> by building the solution. I know what I'd rather do. >>> >>> >>> [and apologies for being deliberately incendiary but I *hate* the >>> movement away from tools in Squeak/Pharo. It is a movement towards stasis >>> and death, and personally I'm enjoying life too much]. >>> >> >> You then have noticed that those threads are about working on tools? >> > > Yes, and that's why I'm writing to the thread. I hope that work on > integrating foreign file support, and integrating things like Chris > Muller's version server continues in the Pharo community. More than > anything I hope that Monticello remains a bridge between the Squeak and > Pharo communities. > I entirely agree with that :) Thierry > > >> >> >> Thierry >> >> >> >> > > > -- > best, > Eliot >
