Hi Dale,


On Thu, Jun 26, 2014 at 3:16 PM, Dale Henrichs <
dale.henrichs at gemtalksystems.com> wrote:

> My favorite feature by far is the ability to look at the git history of
> the methods themselves ... just the other day I had a bug that I was
> tracking down, and by looking at the git history I discovered that a
> critical change had been made to that method 1 year 12 days ago ... from
> that I was able to look at all of the changes to all of the packages that
> had been made in the same commit (the critical code had not only been moved
> to a different class but the critical method had been moved to a separate
> package ... and from that I was able to see that a bug had been introduced
> when not all of the critical method was moved ... bug fixed ...
>

Chris Muller has recently done some superb work in Squeak with his Magma
database that provides exactly this within the existing Monticello
framework.  In current Squeak 4.5 images if you add the repository

MCHttpRepository
 location: 'http://box4.squeak.org:8888/trunk'
 user: 'squeak'
 password: 'squeak'

to the Monticello Browser and then add it to the packages one is interested
in (a script to add it to all is trivial), then a "Browse mc history" menu
item becomes available on the class and method lists in the browser and
voila, one can browse the entire class and/or method history.

This feature has been missing for a long time.  I really needed it this
morning and wasn't quite aware that it was available already.   I expect
this will become a standard feature of new Squeak releases.  The server can
easily be duplicated on one's own machine for working detached from the
internet (e.g. via http://localhost:8888/mchistory) and updates itself at
regular intervals.


>
> Besides method versions, you can look at the git history for a class,
> package or metacello project .... these are thing that would take a bit of
> work to accomplish using just Monticello ... and if you were to attempt to
> do it, the simplest thing to do would be to copy all of the packages into a
> git repository and just use git:) Frank Shearar wrote some code that did
> something along these lines a couple of years ago ...
>

But the work's mostly been done.  Chris's work provides class & method.
 Package history is there already, with "search history" providing free
text search through a specific package's history, and Chris will be
providing keyword search across all packages soon.


> Dale
>
>
>
> On Thu, Jun 26, 2014 at 2:21 PM, kilon alios <kilon.alios at gmail.com>
> wrote:
>
>> another advantage of git is source code searches. It will essentially
>> allow pharoers to search pharo code online and not just being isolated in
>> their image. The search does not return just a whole library but even code
>> fragments.
>>
>>
>> On Fri, Jun 27, 2014 at 12:17 AM, Sebastian Sastre <
>> sebastian at flowingconcept.com> wrote:
>>
>>>
>>> On Jun 26, 2014, at 3:52 PM, Esteban Lorenzano <estebanlm at gmail.com>
>>> wrote:
>>>
>>> On 26 Jun 2014, at 14:56, Sven Van Caekenberghe <sven at stfx.eu> wrote:
>>>
>>>
>>> On 26 Jun 2014, at 19:07, Dale Henrichs <
>>> dale.henrichs at gemtalksystems.com> wrote:
>>>
>>> I think that it is possible to most if not all of the git work support
>>> into the Smalltalk development environment ... I am doing that for GemStone
>>> with tODE[6] and I do find myself going to the go to the command line much
>>> less frequently ... but in tODE I have built a git merge tool and a git
>>> diff tool ... you can get the git history of a method from the browser, etc.
>>>
>>>
>>> Without a relatively high degree of tool integration it can be clunky to
>>> use git ... I am very willing to share what I've done/learned in tODE with
>>> Pharo tool builders and of course I think Thierry Goubier has actually been
>>> ahead of me in several different areas ...
>>>
>>>
>>> That is my analysis: it works today, 'perfectly', but there is not
>>> enough tools support to make it as easy as Monticello as a whole is today.
>>>
>>> If these tools exist, or we can build them quickly based Dale's code,
>>> that would be cool (I guess its all OSProcess underneath, which I find
>>> so/so, a direct integration is better) that would be good.
>>>
>>> Would having this change our world fundamentally ? No, IMHO
>>> Is it worth the effort, is the ROI there ? I don't think so
>>>
>>>
>>> I disagree here. I think moving our development to git will change
>>> deeply (for good) our community processes and then I think it totally
>>> worths the effort.
>>>
>>>
>>>
>>> big +1 here
>>>
>>> The social benefit of having your code exposed in places like github
>>> outweighs by at an astronomical scale the current lack of amazing mergetools
>>>
>>> If your code cannot be exposed without friction you’re done
>>>
>>> The noise of the jungle of
>>> 3-new-libraries-per-day-that-can-be-installed-in-one-shot *will* make
>>> your work invisible
>>>
>>>
>>>
>>>
>>>
>>
>


-- 
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20140717/5373cdfe/attachment.htm