[PATCH 0 of 3] Highlighting for log & graphlog

[Jason Harris]

On May 5, 2011, at 8:43 AM, Peter Arrenbrecht wrote:

> On Thu, May 5, 2011 at 8:28 AM, Jason Harris <jason at jasonfharris.com> wrote:
>> 
>> On May 5, 2011, at 7:19 AM, Peter Arrenbrecht wrote:
>> 
>>> On Thu, May 5, 2011 at 6:34 AM, Jason Harris <jason at jasonfharris.com> wrote:
>>>> 
>>>> On May 4, 2011, at 11:10 PM, Matt Mackall wrote:
>>>> 
>>>>> On Wed, 2011-05-04 at 16:34 +0200, Peter Arrenbrecht wrote:
>>>>>> On Tue, May 3, 2011 at 10:26 PM, Matt Mackall <mpm at selenic.com> wrote:
>>>>>>> On Tue, 2011-05-03 at 22:00 +0200, Benoit Boissinot wrote:
>>>>>>>> On Tue, May 3, 2011 at 9:52 PM, Matt Mackall <mpm at selenic.com> wrote:
>>>>>>>>> On Tue, 2011-05-03 at 21:45 +0200, Benoit Boissinot wrote:
>>>>>>>>>> 
>>>>>>>>>> It is nice for example with "outgoing()", I can easily see how the
>>>>>>>>>> outgoing csets fit into the whole graph.
>>>>>> 
>>>>>> I'm the one who suggested the feature. It was triggered by Benoit's
>>>>>> suggestion that we have a "sample(undecidedset)" revset to visualize
>>>>>> how set discovery takes samples. But there's other uses. Basically, it
>>>>>> boils down to being able to see things in context:
>>>>>> 
>>>>>> * Where was this file touched, on what lines development?
>>>>>> * Same for authors.
>>>>>> * Highlight all ancestors/descendants of this node.
>>>>>> * Highlight this named branch.
>>>>>> 
>>>>>> In fact, I think we should maybe revisit the decision to try and align
>>>>>> log and glog. log is very much about speed and thus always walks the
>>>>>> changelog in revnum order. For glog, however, I think we should value
>>>>>> versatility over raw speed. It's a DAG visualizer. Once we see it as
>>>>>> such, we can do things like:
>>>>>> 
>>>>>> * Walk from all heads in breadth-first manner to get an overview of
>>>>>> what the heads are (maybe not exactly breadth-first, but a couple of
>>>>>> nodes at a time).
>>>>>> * Use the linearizing toposort of shrink-revlog and combine it with
>>>>>> the elision of linear runs (an old patch of mine) to get a concise
>>>>>> overview of branching/merging in a tree.
>>>>>> 
>>>>>> glog is very much about DAGs. I already took a first step in the
>>>>>> direction of making DAGs first class with dagutil.py (introduced by
>>>>>> set discovery). Benoit is working on moving the shrink-revlog toposort
>>>>>> there. Maybe we could also move Patrick's "redagging" (rebuilding a
>>>>>> DAG from a disconnected revset) there. So the more general DAG algos
>>>>>> would be clearly separate from visualizing them.
>>>>> 
>>>>> Teaching revlog's sort() about toposort might be useful.
>>>>> 
>>>>>> Then we could base glog on the DAGs exposed by dagutil. And we could
>>>>>> also easily add support for other visualizers like dot (which should
>>>>>> be configurable so it immediately launches a renderer and viewer) and
>>>>>> hgweb.
>>>>>> 
>>>>>> This way, glog and other visualizers could make the power of revsets
>>>>>> even more awesome.
>>>>> 
>>>>> I'm all for making glog cool. But I disagree about aligning it with log.
>>>>> People are going to continue to expect feature parity with log where it
>>>>> makes sense. And the current implementation of log is horrendous to the
>>>>> point where it's no longer maintainable. By being reimplemented in terms
>>>>> of revsets, I think graphlog has already passed it up.
>>>>> 
>>>>> Check this out:
>>>>> 
>>>>> $ time hg log -b stable -q | wc
>>>>>   1238    1238   23481
>>>>> 
>>>>> real  0m2.564s
>>>>> user  0m2.413s
>>>>> sys   0m0.100s
>>>>> 
>>>>> $ time hg log -r 'branch(stable)' -q | wc
>>>>>   1238    1238   23481
>>>>> 
>>>>> real  0m2.145s
>>>>> user  0m2.040s
>>>>> sys   0m0.073s
>>>>> 
>>>>> Revsets are faster (and much more powerful) than log's engine, and
>>>>> that's even before the optimizer has gotten the chance to do anything
>>>>> clever. The current log code wants to die, though we'll need to teach
>>>>> revsets a bit about the file fast path first.
>>>> 
>>>> I would just comment (to hammer home the obvious) that external programs make heavy use of log and the speed of log is directly proportional to the speed of some of the Mercurial GUI's like eg MacHg, etc.
>>>> 
>>>> Also visualization is a cool topic but at some point you just get diminishing returns with ASCII based terminal visualization. At some point you need to switch to real graphics, subtle color shades, highlighting, etc. Thus its quite important that Mercurial allows speedy and easy access to these things so that the data can be grabbed for higher level visualization tools.
>>> 
>>> True, true. Glog takes you quite far, but as I said, I really think we
>>> should have an interim representation of the sets and dags, including
>>> emphasis, that is available to external tools. Some sort of JSON
>>> representation maybe. And it's important that it operate at an
>>> abstract DAG level (not on the base revlog DAG) so it can accommodate
>>> alternate topologies like Patrick's condensed DAG. It should also
>>> support different node types (csets, elisions, whatever) as I have
>>> already introduced in graphlog earlier. And maybe something like CSS
>>> styling hints.
>> 
>> Yes that would be quite nice. Regrettably, I find the output of debugdag quite hard to follow (and maybe this is just intrinsic to what its doing) or maybe its just my fault, and clearly the need for such a thing like debugdag is undeniable.
> 
> This output is not meant to be read by humans, but by things like
> debugbuilddag, or by other parsers hooked up with glog, for instance
> (I used this to compactly represent large DAGs during development of
> setdiscovery).

Yep. I understand its purpose. I am just saying I still couldn't understand it even
then. Ie I couldn't understand it enough to write a parser to get the relevant
information out of it. I have looked at documentation in dagparser.py but after
trying to fathom out what was going on here I gave up. I guess if I really studied
it I would be able to understand it... Still its pretty opaque to me :)

Thanks,
  Jas