Hi Eliot,

thanks for that mail.

2014-12-04 23:59 GMT+01:00 Eliot Miranda <eliot.miranda@gmail.com>:

Hi Thierry,

On Tue, Dec 2, 2014 at 10:25 PM, Thierry Goubier <thierry.goubier@gmail.com> wrote:

2014-12-03 4:16 GMT+01:00 Eliot Miranda <eliot.miranda@gmail.com>:

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