bharry's WebLog

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).

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

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.  :-)

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

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...

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.

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.

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.

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

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

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

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

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.

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.

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.

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

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

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.

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