[dev] [cvs] commit: chora annotate.php chora/templates/annotate header.inc line.inc chora/themes screen.css

Jan Schneider jan at horde.org
Wed Jan 7 17:50:15 UTC 2009


Zitat von Michael M Slusarz <slusarz at horde.org>:

> Quoting Michael Rubinsky <mrubinsk at horde.org>:
>
>> Quoting Jan Schneider <jan at horde.org>:
>>
>>> Zitat von Michael M Slusarz <slusarz at horde.org>:
>>>
>>>> slusarz     2009-01-07 01:13:07 EST
>>>>
>>>> Modified files:
>>>>  .                    annotate.php
>>>>  templates/annotate   header.inc line.inc
>>>>  themes               screen.css
>>>> Log:
>>>> Rework annotate screen - prevision revision number is not all that
>>>> important.
>>>> What is important is a link to the diff between the changing
>>>> revision and the
>>>> previous revision (the previous revision can be viewed in its entirety by
>>>> following the appropriate link on the diff page).
>>>
>>> Again, I strongly disagree. I use this all the time to navigate back
>>> through history until I find the actual revision where a change was
>>> really made, to skip revisions where a change was just cosmetically.
>>
>>
>> I agree with Jan on this (as well as the log info remaining in the
>> annotate view). IMO, an awful lot of the reason for me using annotate
>> (at least with non-git repos) is lost with these changes.
>
> Apparently the way I use annotate is completely different than  
> everyone else (although, from past history, that doesn't surprise me  
> :))  My problem with the way that everyone else does things is the  
> following: if you click on the previous revision, and the change you  
> are looking for is at line 5000, are you saying you have to scroll  
> all the way down to line 5000 and then manually eyeball the section  
> to see if it changes?  That is entirely unacceptable to me.  It makes

That's exactly how I use it, and the good thing is that it already  
scrolls down for you to that line. It's not always accurate of course,  
because the line number is just used 1:1, but it's a good approximate.

> a lot more sense to view a diff between the two revisions which,  
> depending on the size of the commit, won't require scrolling at all.  
>  Then if the change is cosmetic only, you can click on the previous  
> revision on the diff screen to go to that revision, and then you can  
> click on Annotate on that page.  Granted it does require an extra  
> click to get to the next annotation, but on the flip side the server  
> is doing all the comparing rather than your eyeballs.
>
> Still heartily disagree with the log tooltip.  Given the existence  
> of the diff icon now, the log tooltip is complete overkill and (with  
> large files) is a total resource hog.  I can actually view  
> imp/lib/Compose.php now without it threatening to crash my browser  
> (we're talking about a dual core CPU with many GB of memory) - which  
> was one of the reasons that made me change this in the first place.   
> Additionally, as previously mentioned, displaying log entries for  
> git files that have been renamed is a non-trivial thing.  git  
> rev-list only displays revisions for the file as currently named.   
> If changes were made before the file was renamed, then you have to  
> go produce a log entry of that entire file and so-on until the git  
> repo origin is reached.

I agree that the log tooltip is a huge resource hog and I alway  
disliked that. But it's really helpful if you use history/annotation  
like above, because you can often see with a single look whether the  
linked diff is really what you are looking for.
I think it would be great to load the tooltip with an ajax request  
instead, that would get us the full feature without the performance  
loss.

> I guess the solution for the former is to re-add the Previous  
> column.  As for the log tooltip, if re-added, this would make most  
> sense as a tooltip to the diff icon.

Agreed, a diff icon (if you talk about adding one to the annotate  
view) is the better place for the log tooltip.

Jan.

-- 
Do you need professional PHP or Horde consulting?
http://horde.org/consulting/



More information about the dev mailing list