A new look for Annotate

re: A new look for Annotate

William Bartholomew — Fri, 06 Oct 2006 02:48:18 GMT

Brian,

I think it would be assume to lose the date, it's one of the more important things there... I'd rather lose the changeset number and make the date clickable, and have the changeset number in the tooltip.

The other thing that would be cool is if the shading was actually based on the age of the changeset. When you're looking at the annotate output you're primarily going to be looking for code that caused a problem or for a feel when code was changed. I was thinking the shading could represent age categories (today could be red, this week organge, this month yellow, otherwise green, or something like that).

re: A new look for Annotate

Steve St.Jean — Fri, 06 Oct 2006 02:50:05 GMT

Looks really good. I gave a presentation on TFS to my company's devs and the dev leads found the Blame...er, Annotate feature to be a big help when the CI build breaks.

- Steve

re: A new look for Annotate

Keith Hill — Fri, 06 Oct 2006 08:08:00 GMT

I agree that date is more helpful than changeset # - at least make it appear in a tooltip. From the date I can quickly see when the last change occurred on a line which I can correlate with when a bug appeared. I would also like to see some visual guides in the editor to help me line up code that is extremely indented (far away from the info column on the left). Perhaps if I select a particular changeset, the corresponding lines have their background color changed slightly?? Also, is there a reason you just don't call it blame? Everyone around here using it is calling it that anyway. :-)

re: A new look for Annotate

aelij — Fri, 06 Oct 2006 12:22:09 GMT

I also agree the date is important. Just last week I caught the culprit who broke a build using that. Keith, I love "Blame" :-)

re: A new look for Annotate

Adam — Fri, 06 Oct 2006 12:58:40 GMT

Wow! That was quick! :)

Heh, the "back" I was referring to in my comment to the other post yesterday was comparing that screenshot (I know I called it new, even though it was a month old, sorry about that) against the last screenshot I'd seen here

http://blogs.msdn.com/buckh/archive/2006/03/13/annotate.aspx

IMHO, changing the orientation of the gradient has helped a lot though, as has removing (or at least greatly reducing) the width of the separator between the annotations and the source. It looks a lot less like the outlook sidebar now.

I'm still not sure what the highlighted annotation indicates.

I'll disagree with everyone else about the date/revision number importance. I often want to follow the history of a particular line of code, so knowing which revision a line last changed on makes it easy to get the revision /previous/ to that one to re-run annotate on. That way I can see who changed it the time before last. And then the time before that, etc...

re: A new look for Annotate

bharry — Fri, 06 Oct 2006 13:45:09 GMT

Great feedback! I love the idea of color coding based on age. We'll look into that. Not sure if we can get it done this time around but it's a neat idea.

Misc responses -

Ahh, I don't know why we don't call it blame. Many people do, but I don't really like the negative connotations with it. I have to admit it's being a bit arbitrary but "annotate" seems a bit kinder and gentler :)

Date/Time - I should have been clear, it is in the tool tip along with the first couple of hundred characters of the comment. Does this help? We talked about replacing the changeset number with the date but then two checkins on the same date would be indistinguishable and adding the time seemed to add too much noise. Our original spec called for a config dialog that would let you configure the columns but that got cut for time :( I suspect we'll get that back in there at some point.

Coloring in the editor - Yeah, we wanted that too. We ran into a limitation in the VS editor. If we try to change any color aspects in the editor window, we lose syntax coloring. We've talked to the editor team about enabling both and we'll work for it in a future version but out call was that syntax coloring was the more important of the two. Do you agree?

The highlighted region indicates where your cursor is in the text window. The thinking is that helps alleviate the problem of not shading the regions in the text window and gives a visual cue to which changeset the line they're on is in.

Thanks for the feedback. Always looking for more...

Brian

re: A new look for Annotate

David James — Fri, 06 Oct 2006 14:59:08 GMT

Many thanks, Brian, for putting this up for comment.

I would also like you to keep the date visible. In addition to what other commenters have written, there are a few situations when we regularly use the date.

Firstly, we will often have a situation where someone checks in a large piece of work, then after the build server has reported unit test results, the same person may check in a few smaller changes to fix some failing unit tests. Although these appear in annotation as separate changesets, when we read the dates in the annotation we can see that they're close together, and we can think of them as one change.

Secondly, we imported all our code from another source control system, but we were unable to import history. When we see the date of "14 April 06" we remember that the change we're looking at is simply the commit that added everything to TFS.

Lastly, consider the case where we discover a new bug and we annotate the source. If we see a change on "6 Oct 2006" we can immediately tell that it's a very recent change, so we pay attention to it. If we only see changeset "22126", it is not obvious how recent it is.

Regarding Adam's comment about using the changeset number as input to another command - I also find the changeset number useful in this situation, but if I had to choose, I'd prefer the date to be always visible and the changeset to be on a context menu/tooltip. (If you're going to be using the changeset number to run another command, you'll be reaching for the mouse anyway, so it's less time-consuming to go to a context menu.)

Maybe we should think about Brian's words "more readable" - this is not the same as "more useful". Removing the date and/or the changeset probably *does* make it more readable, but it also makes it less useful. My personal preference would be to keep it how it is now, with both date and changeset, because they're both very useful.

re: A new look for Annotate

Keith Hill — Fri, 06 Oct 2006 18:33:30 GMT

OK so if you can't change the colors in the editor without loosing syntax color (which is important for readability) how about this. Can you draw subtle horizontal lines in the editor window that would line up with the various annotate sections? I use CodeRush and they do this with regions. The line needs to be pretty subtle so that it doesn't add too much visual noise - just enough to help you know which changeset a particularly deeply indented piece of code is in. Having the annotate region highlight based on where the caret is, is OK but it isn't great when you want to quickly scan code.

re: A new look for Annotate

Keith Hill — Fri, 06 Oct 2006 18:38:43 GMT

BTW I agree with David that having both the date and changeset displayed is very useful but if you could only display one - display the date.

re: A new look for Annotate

bharry — Fri, 06 Oct 2006 23:41:14 GMT

OK, time for a bit of feedback "feedback" :)

Showing the date - We hear you, Chad is changing it back now :) We're going to put in a registry key for people who'd rather not have it show the date but we're going to skip the config UI for time.

Coloring based on age - We're going to experiment with a few possibilities here. We're near the end of our coding for this feature so I can't promise we're going to get it but we're going to play around and see if we can hit on something quickly that looks good.

Shading/lines in the text - Anything we do here likely means subclassing the editor window and snooping the paint event. I'm a bit worried about how reliable this will be but we're going to play with it a bit and see if we can make anything work.

A question Kevin (the PM) asked - We display the user name in the margin. In principle, that user name can be up to 32 or 64 characters (I forget). We don't trim it to limit the horizontal space usage. Do you thing we should use elipses after it passes 12 chars or so?

Thanks for listening,

Brian

re: A new look for Annotate

Keith Hill — Sat, 07 Oct 2006 01:42:02 GMT

Around here 12 chars would be plenty to display the whole username. So I would be OK with using ellipsis.

re: A new look for Annotate

Keith Hill — Sat, 07 Oct 2006 01:47:38 GMT

BTW how about the idea of drawing faint horizontal lines instead of shading the text? It seems like that might be easier.

re: A new look for Annotate

Scott Lee — Wed, 11 Oct 2006 16:09:22 GMT

Brian,

First of all thanks for putting the date back in...

As far as adding elipses for the username... I think that sounds like a good idea. You don't want the left hand side to overextend too far into the code area as you want more space in the code then the left hand bar...

thanks for listening!

~slee

VSTS Links - 10/12/2006

Team System News — Thu, 12 Oct 2006 20:27:03 GMT

Brian Harry on A new look for Annotate. The Vertigo Software Team System blog on When should I create...

re: A new look for Annotate

Adam — Tue, 17 Oct 2006 12:30:53 GMT

Yeah, I guess the date does make a fair bit of sense as the default. So long as the revision is also easily accessible (e.g. via tooltip) then that's not going to be a problem for workflows that need it.

re: A new look for Annotate

Carl Daniel — Fri, 20 Oct 2006 01:47:12 GMT

Blame... er, Annotate.. is cool. One thing I'd like to see - include inherited (pre-branch) history in the annotation. On the date versus changeset subject, I actually prefer having both and have no problem with the screen real estate that having both takes up.

re: A new look for Annotate

Chkalofff — Fri, 20 Oct 2006 16:15:47 GMT

The current Annotate version displays ChangeSet #, Changed By and Changed Date fields. Besides the Comment field for Changeset is shown

when you place a mouse cursor at it.

It seems to me that rather often a user is willing to know not only by whom and when the group of lines in the source code was changed but also what was

the reason of the change. As a result the Associate Workitems should be displayed, too. Also when a mouse cursor is set at a certain WorkItem a tip for the WorkItem should be shown.

As we can see there are too many fields with the Annotate information. I suggest a set of fields should be customizable. Customization should be done using

Tools/Options menu item. More than that, in that case a user must be able to hide all the fields except the framework limiting the group of lines in the source code. When the focus is set at the framework the user gets a pop-up tip. When the framework is double-clicked the ChangeSet Details must be opened.

Another approach is to make the Annotate panel move back and forth.

Here's one more important moment. I think the Annotate mode should be merged with the Edit mode so that a developer be able to receive at any moment the Annotation of the open file in the same window where the file is being edited. Various approaches can be used:

1. The Annotate mode is started at the same time when the file is being opened but on the background so that not to slow down the opening of the file.

2. The Annotate is NOT started at the same time when the file is being opened but the mode can be switched on and off by pressing a toolbar button or through the View Menu item.

All described above will be of great use for the future version of the Powertoy. I think.

At the horizon: What are Microsoft's plans for the next version of Visual Studio - code-named "Orcas"?

Neno Loje's Treasury — Sat, 28 Oct 2006 02:57:19 GMT

"Orcas" is the code name for the next version of Microsoft Visual Studio - "the next generation...

At the horizon: What are Microsoft's plans for the next version of Visual Studio - code-named "Orcas"?

Visual Studio Team System (VSTS) Blog — Sat, 28 Oct 2006 13:18:24 GMT

"Orcas" is the code name for the next version of Microsoft Visual Studio - "the next generation

re: A new look for Annotate

samunro — Tue, 20 Nov 2007 00:30:44 GMT

I feel that this feature is not as useful as it could be because of its focus on the most recent change. When I am trying to identify when (and by whom) a particular change was introduced, I am not interested in subsequent, unrelated changes.

I would prefer the ability to view a history of each line with an interface similar to that of the file history feature.

Visual Studio Team System 2008

Yo sólo pasaba por aquí pero ya que estoy.... — Wed, 05 Dec 2007 00:03:33 GMT

Como muchos ya sabréis hace poco Microsoft lanzó al mercado Visual Studio 2008. Si estáis

A new look for Annotate

re: A new look for Annotate

re: A new look for Annotate

re: A new look for Annotate

re: A new look for Annotate

re: A new look for Annotate

re: A new look for Annotate

re: A new look for Annotate

re: A new look for Annotate

re: A new look for Annotate

re: A new look for Annotate

re: A new look for Annotate

re: A new look for Annotate

re: A new look for Annotate

VSTS Links - 10/12/2006

re: A new look for Annotate

re: A new look for Annotate

re: A new look for Annotate

At the horizon: What are Microsoft's plans for the next version of Visual Studio - code-named &quot;Orcas&quot;?

At the horizon: What are Microsoft's plans for the next version of Visual Studio - code-named "Orcas"?

re: A new look for Annotate

Visual Studio Team System 2008

At the horizon: What are Microsoft's plans for the next version of Visual Studio - code-named "Orcas"?